Tortuga 1.0 Plugins, What will they be?

[Lee Olayvar]

I'm just curious if we can develop a small list of plugins planned/desired for the 1.0 release. This will give me (and hopefully others) an idea of what will and wont be needed, along with what functionality will be provided by the core and not a plugin (Eg, a "user authentication" plugin will not be needed, as that will be handled by the core.. if i recall correctly).

Some examples are:

 - News/Blog, Allowing for publication of stories/etc.
 - Gallery
 - Forums
 - Comments

Though, these may not be the best examples. I would hope we take the approach of abstraction to the extent that forums/comments/blog are essentially the same codebase. Since forums are really nothing much more than an original thread, with comments, just like a blog is nothing but an original thread with or without comments, etc.


Thanks,
--
Lee Olayvar

[Ian Charnas]

Lee, I think News, Blog, Photo Gallery, Tags, embedded Video (youtube,
etc) and Audio (flash mp3 players), Forms, and Comments will all be
present in the 1.0 release. I know that for me, currently I have
about 40 web clients, and these are the things I find myself using
most often in the real world.

I don't know about Forums, personally I don't think I can do a better
job than google groups.

I don't think that we can realistically abstract forums, comments, and
blogs to be the same thing. Comments will involve captchas and be
threaded, Blogs will involve authentication and RSS and not be
threaded, and Forums involve a news<->email gateway that's incredibly
difficult to get working with all the email systems out there. They
are similar in that they are text-based, but beyond that I think they
are very different.

ian

[Chris B - JK at asciiking dot com]

On Dec 21, 9:24 pm, "Ian Charnas" <ian.char...@gmail.com> wrote:
> I don't think that we can realistically abstract forums, comments, and
> blogs to be the same thing. Comments will involve captchas and be
> threaded, Blogs will involve authentication and RSS and not be
> threaded, and Forums involve a news<->email gateway that's incredibly
> difficult to get working with all the email systems out there. They
> are similar in that they are text-based, but beyond that I think they
> are very different.

There's a substantial overlap in the data structures between forums,
commented blogs, mailing lists and newsgroups. The technical
difference is mostly presentation, but that has social implications.
I'd like to experiment with blended presentation because having
multiple communication vectors on a site fragments content, but it is
probably better to focus on the content type that best fits the
character of a given site and extend it in whatever ways make sense
locally - meaning that user-driven sites should start from a forum-
like presentation and add blog-like abilities for key posters to
"push" and "tag" thread starts while sites with a top-down structure
should start with blogs then work towards making the comment structure
richer. It's good to make the options available, but I hope that our
deployment recipes tend more towards building interesting content
types well. The potential that I see in this platform would be wasted
implementing parallel content streams for the sake of building a
feature list.

I also think that forums, email notifications, and mail <--> news
gateway don't necessarily have to be implemented all in a go. We're
certainly not expecting our hobby and small business sites to compete
with Google feature for feature. The reason for not using Google or
Yahoo is "who owns my content." That's a question that's more relevant
to blogs than forums, but I think it would be worthwhile for some of
us to plan on building forums and relational (in the social sense)
content types. I understand Ian's priorities here, so we should
probably be thinking about building that one as a contrib. Put
together a roadmap: forum -> optional notifications -> real time mail
updates -> post from email. The news gateway, at that point becomes a
deployment recipe.

There seems to be some demand for FOSS SNS and I think that a product
coming out of a Python -> Web Framework -> CMS stack will have a user
base with healthier expectations than Elgg experienced. Maybe someday
we'll have the problem of meeting the expectations of those who use
advertising supported and $2/mo hosting, but today the barrier to
entry for Python hosting works in our favor.

Another major application that could be an important 3rd party plugin
would be an e-commerce package.

Chris

[Lee Olayvar]

Sounds good. Just for the record i wasn't asking to make sure Tortuga would have things i wanted, but rather so that i could develop some things that wouldn't be replaced later on.

Also, I do not feel that abstracting forums/news/tags/comments/etc is impossible. Though its difficulty will be based around Tortuga's API to begin with, and i do feel its better to push out a final product, rather than spend extra months working with nothing usable, simply for the sake of getting this golden abstraction goose. Just to get an idea though, Drupal roughly has what i am talking about. It has a "Tag" system, a Content Submission System, and a Comment System. With these three things, they managed to create forums & news simply by binding them together. Though i do think their comment system has much left to be desired, as it works fine for News, but for forums there is a visibly defined line between the original thread poster, and people replying to that thread. So i'd much rather see it not done at all, and possibly slowly worked on, rather than push out a clunky 1.0 release.


Anyway, i got an idea of what will be the goal of 1.0's plugins, so thanks :)

--
Lee Olayvar

[Ian Charnas]

Chris, Lee -

Thanks for your comments. I'm sure that we'll have certain features
like permalinks to blog entries, comment moderation, user-ratings (1-5
stars), and so on. When you say that you are interested in seeing
comments and blog entries based on the same code, is there a
particular feature or interaction you were hoping for? I mean
certainly deep in the code, it's not important to keep comments and
blog entries in the same database table. Let me know, and I'll keep
this in mind when I get to developing the blog and comments plugins.

ian

[Lee Olayvar]

Nah, for me i simply would like to see as many aspects as possible benefit from a single codebase. So in the future, improvements to a Comment plugin would be spread through the entire site. Eg, it would improve forums, blogs, polls, etc. But as i mentioned before, i see no reason to force these concepts onto 1.0, and delay its release because of this. I'm sure common libraries will evolve one way or another no matter what.

--
Lee Olayvar

[Chris B - JK at asciiking dot com]

On Dec 22, 11:06 am, "Ian Charnas" <ian.char...@gmail.com> wrote:
> Chris, Lee -
>
> Thanks for your comments. I'm sure that we'll have certain features
> like permalinks to blog entries, comment moderation, user-ratings (1-5
> stars), and so on. When you say that you are interested in seeing
> comments and blog entries based on the same code, is there a
> particular feature or interaction you were hoping for? I mean
> certainly deep in the code, it's not important to keep comments and
> blog entries in the same database table. Let me know, and I'll keep
> this in mind when I get to developing the blog and comments plugins.

I'd actually rather see features like "tags", "ratings", "comments",
"social", etc. be distinct plugins as opposed to being features that
need to be implemented for blogs, *and* photo gallery *and* media...
In that way, the interfaces across the differing content types would
automatically be consistent and it would be easier to maintain the
feature set when new content types are added.

For comments and forums, I'm particularly interested in threading as a
user option. In general, I'm looking for ways to make social
interactions more natural to follow.

One of the ideas that I've been kicking around is allowing the reader
to select the view. The basic fields in the underlying data type are
id, parent_id, preferred_view and content_blob along with date fields
or whatever else. Then there's a many to many table that maps whether
content with a given preferred_view is compatible with the current
view. Users have the option of seeing all compatible content for a
view or only the content for which the current view is the preferred
view. The idea is to provide different text content types without
isolating pockets of content. This is particularly relevant for
smaller sites that want to implement competitive features without
making it excessively difficult for users to see that new content is
available.

Chris

[Chris B - JK at asciiking dot com]

On Dec 22, 9:15 pm, Chris B - JK at asciiking dot com

<swift2plun...@gmail.com> wrote:
> One of the ideas that I've been kicking around is allowing the reader
> to select the view. The basic fields in the underlying data type are
> id, parent_id, preferred_view and content_blob along with date fields
> or whatever else.

Oh, in case someone *does* implement something like this at some
point, I probably should mention that the "whatever else" not only
glosses over some obvious things like a title, but a little detail
that might be important...

If you try to build a web page by doing recursive lookups to walk a
thread, you'll have a really slow page. That might be cool to watch in
AJAX, but it would be even better to just load faster. To get around
this, you need to be able to pull all the descendants by querying an
"eve_id" that identifies the original ancestor for each record.
Alchemy will cache the results. When you look up relationships for
threading, it's a matter of making sure that the search stays in the
cache. I expect that to be trivial, but I could be disappointed.

Chris

[Ian Charnas]

Thanks Chris.

> I'd actually rather see features like "tags", "ratings", "comments",
> "social", etc. be distinct plugins as opposed to being features that
> need to be implemented for blogs, *and* photo gallery *and* media...
> In that way, the interfaces across the differing content types would
> automatically be consistent and it would be easier to maintain the
> feature set when new content types are added.

Right, that's the plan. Tags, ratings, and comments are definitely in
the plans. I'm actually working on the model for Tags right now.
That's a good one to demonstrate because it's many-to-many, and it's
worthwhile to revision and localize it, so it demonstrates all the
features of tortuga database core at once.

We'll talk about a "social" plugin after a 1.0 release.

> For comments and forums, I'm particularly interested in threading as a
> user option. In general, I'm looking for ways to make social
> interactions more natural to follow.

Let me know if you see any threading systems you like.

[Chris Babcock]

> I'm actually working on the model for Tags right now.
> That's a good one to demonstrate because it's many-to-many, and it's
> worthwhile to revision and localize it, so it demonstrates all the
> features of tortuga database core at once.

Does this mean an administrative interface to change misspelled tags,
kill tag spam, select capitalization rules, undo "whoops I killed the
wrong spelling" and perpetuate tag translations into translation of
new documents? Rhetorical question. If it ended after "administrative
interface" with a "yes" I'd be a happy boy.

> We'll talk about a "social" plugin after a 1.0 release.

Neil Blakey-Milner did one for Gibe, a TG1 blogging engine:
http://nxsy.org/tgsociable---a-turbogears-port-of-the-wordpress-sociable-plugin

Just so that I don't have to look it up again. ;-)

> > For comments and forums, I'm particularly interested in threading as a
> > user option. In general, I'm looking for ways to make social
> > interactions more natural to follow.
>
> Let me know if you see any threading systems you like.

There are two basic type of threaded reply content that, for lack of
formal training, I tend to think of as "clients" and "peers". Blog
comments and comments on other media that are secondary to the root
content are clients that benefit minimally from threading and perhaps
more from services like disqus. When the replies are peers to the root
content, for example forums and mailing list archives, then threading
potentially holds a lot of content information. I like the same model
for both, but they should be displayed differently. If the client
threaded reply model is sufficiently robust then you've already paid
for the peer model. All that's left is presentation. ;-)

Here's a threading algorithm I found on Jamie 'no Magic Bullet'
Zawinski's site that's robust enough for email (and therefore usable
in the less demanding role we want):
http://www.jwz.org/doc/threading.html

Regrettably no code, but the algorithm does deal with missing parents
and provide a method for organizing threads without depending on
Alchemy not to go back to the database. An object-oriented
implementation would be a joy to deploy.

Chris