[typo] More medium/long term Typo goals
scott at sigkill.org
Wed Aug 2 12:55:00 EDT 2006
I mostly agree with Piers. Here's a short version of my list (short,
because I'm on vacation this week):
* Finish the url_for cleanup. All Content model objects should
support a permalink_url (or similar) method that returns a link to the
permalink for the object. Maybe an edit_url and delete_url,
too--that'd clean up some of the views.
* Helper cleanup--there are zillions of duplicate ways to get URLs and
so forth buried in out helpers. Clean them up, standardize, optimize,
* Add rdoc where appropriate.
* Query optimization--the front page (sans sidebars) should take 3
queries: blog_id, article count, page 1 article bodies. We're down to
~30 now, from 300 late in the 4.0 dev cycle. Sidebars should be
cleaned up where possible, so they're fast.
* Optimization. Faster, faster, faster. With less RAM.
* Remove components. They were a nice idea. At least according to
the Rails docs. However, it's unclear that anyone else uses them for
anything. We've certainly found substantial bugs in them that no one
else caught. Plus, they're slow. Make it possible to bundle
sidebars, themes, and text filters into Rails plugins, and build some
sort of infrastructure to make this easy for users. Then move most of
the non-core sidebars out of the main tree.
* Clean up the admin UI. Everyone has ideas on this. I'd love to see
a few mockups.
* Threaded comments. I miss mine. I have a model that is fairly
simple, I'll show it to people later.
* OpenID consumer and producer. Typo should be able to use OpenID to
authenticate comment posters *and* act as an OpenID producer so people
can use their blog as their identity.
* Lightweight permissions model. I'd like to be able to keep
commenter preferences in the user table, so we can send out email
notifications when people follow up on their comments. I *DON'T* want
a 50-table complex permissions model.
* Multiblog support. Ignoring the permissions problem, we're 95% of
the way there already.
* Better Jabber/XMPP support. I'd love to be able to send Atom over
XMPP. There's a spec for it out, although it has issues. I'd really
*love* to merge OpenID, some sort of Typo registry website, and XMPP
to make cross-Typo comments and trackbacks much more powerful then
they are now.
* Atom Publishing Protocol. I love the Atom publishing protocol. Go
play with the Google Calendar API for an example of what APP is able
to do. There's a bit of a problem with it and Typo, though--our text
filter model doesn't really fit into APP's view of the world. I
talked with Tim Bray about it a bit at OSCON, and I think I see a way
* Standardized import and export scripts. I'd *love* to be able to
say 'typo import /some/path wordpress /tmp/foo'. Similarly, we could
standardize some sort of Atom-based Typo export format.
In all honesty, I don't expect to get most of this done for 4.1. I'd
be happy if we could do a bit of permissions work, fix the URLs, ditch
components, and speed things up. I'd really like to have 4.1 out
On 8/1/06, Piers Cawley <pdcawley at bofh.org.uk> wrote:
> Remember this:
> Well, once I've checked in my current local branch which implements a
> feedback specific state machine, we'll have hit most of those goals,
> so it's time to think about a few more.
> Outstanding/Short Term
> * Finish working through the implications of the new state machine
> based content 'state'. Essentially, 'published?', 'spam?' and a few
> other flags are now delegated to the content's state. Any behaviours
> on an object that do anything like:
> if self.published?
> should have the '...' turned into a method on the state objects and
> get rewritten as
> * Something similar applies to some of the things the controllers are
> doing. Structural code (where controllers treat objects as nothing
> more than data structures) is anathema, behaviour should be pushed
> to the model where it makes sense. Controllers shouldn't access the
> state directly, so state dependent behaviour should be pushed to the
> model first and then delegated to the state object.
> * Various of the delegated query methods could usefully be added to
> the model's table, to help with searching. For instance, it would be
> useful for the feedback page to list only those items which are
> probably spam. Which means adding 'spam' and
> 'classification_is_certain' (lousy name, need to find something
> better) booleans to the contents table to help with
> searching. (Controllers don't (and shoudln't) know about the state
> objects, they just know about the query methods, so we need flag
> fields corresponding to the query methods which can be used as find
> * Make page caching work right. Still on my todo list, but not quite
> so urgent as it was. It's in this section because it's one of the
> things that haven't yet been done from the last goals post.
> * Give the theming section a long hard look. Yay! We have Scribbish in
> the core now. However, theming still needs looking at. Wouldn't it be great
> if you could just drop a theme in vendor/plugins and have it appear
> in Typo's list? Wouldn't it be handy to support theme specific
> configuration? Woudln't it be useful if all this was documented?
> * Blog settings. Hmm...
> * Text filters not being controllers.
> Scott's doing some work on making url_for work without having to get
> at the current controllers all the time. Once that's done it should
> be a great deal easier to turn textfilters into models. Again, it
> would be good to be able to write textfilters so they could be
> dropped into vendor/plugins
> New stuff
> * Authentication. I've posted about this before, but we should really
> support, at the very least, OpenID as well as our own internal users
> * Authorization. Once we can authenticate, we can authorize. Some
> blogs might choose require authentication before allowing anyone to
> comment, or automatically mark any unauthenticated comments as
> * Pluggable Spam classification. Right now, when feedback is created,
> it's in the 'Unclassified' state. Saving it 'collapses' it to one of
> 'PresumedSpam' or 'PresumedHam'. The method for doing this
> classification is currently hardwired. First we check our own Spam
> Protection library, then, if it's turned on, we ask Akismet.
> Which is all very well, but what happens if we decide we want to use
> Authentication as a factor in classification? What if someone writes
> a captcha plugin (which gets no nearer to Typo than vendor/plugins
> So, we need to think about making the classification system into a
> dynamic pipeline attached to the blog. My current thinking is that
> this would be configured like sidebars are now (though possibly not
> at the model level, about which more later). The administrator would
> be presented with handy drag and drop interface and drag
> classification tools into a pipeline. So, I might have a pipeline
> that looks like:
> is_logged_in -> article_age -> blacklist -> akismet
> While someone else could have
> captcha -> article_age -> blacklist -> presume_ham
> each engine in the chain would look at the feedback and return one
> of :ham, :spam or nil, where returning a symbol halts the
> classification process, otherwise the feedback goes to the next
> classifier in the chain. Something similar could be done at the
> point that spam is firmly classified by the administrator; each
> engine would have their #report_as_spam/ham(feedback) method
> called and they'd do the reporting as they chose.
> * Multiblogging. I'm so in two minds about this. I think it's going to
> happen, and I *don't* think it's going to have an enormous impact
> on the performance or copmlexity of the rest of typo. Introducing
> the blog object has proved to be The Right Thing, for all its
> teething problems.
> * RESTful API. I like REST. It just makes sense to me. But Typo
> isn't all that RESTful. Article permalinks are, of course,
> sacrosanct, but pretty much everything else is fair game. In the
> long term, I'd like to see the back of admin/* in favour of moving
> administrative behaviour up into top level controllers and slightly
> more complicated access control. This is definitely branch
> territory, if only because the support for the sort of thing I'm
> thinking of has only recently gone into edge rails.
> * Migrations. Migrating is hard. It's hard to keep the migration
> scripts up to date. So, I propose firming up the various message
> posting protocols we have, documenting them, and then sticking to
> them both in our controllers and any migrations we use. I envisage
> using something like the Atom API as our basic posting protocol.
> * Implement the Atom API.
> * Use the rails plugins directory. If you write textfilter, or a
> sidebar, you want some easy way of distributing it. And we want not
> to have to stick it in the core distribution. It seems that the best
> way to do this is to enable writing plugins that can be installed in
> the same way as any other rails plugin. I *think* that this can
> already be done, but it's completely undocumented. We need to
> investigate this and, if it will work with the current state of the
> art, we need to write generate tasks to allow a plugin developer to
> ./script/generate sidebar|textfilter|theme
> and have a framework dropped in place so she can get on with the
> hard work of making it do something interesting.
> * Investigate other blogging engines' plugin architectures. See if
> we're missing any capabilities and what we'd need to do to import
> any useful stuff into Typo.
> Hmm... that'll probably do for now. Did I miss anything?
> Piers Cawley <pdcawley at bofh.org.uk>
> Typo-list mailing list
> Typo-list at rubyforge.org
More information about the Typo-list