I've just been chatting with sprewell on IRC and it occurred to me that it might be handy to share my current development priorities for typo with the wider list.
Immediate goals --------------- * Finish the work on making article publication use a state object * Possibly look at making the state object be persistent as a memento on the Content object * Knock off a few more low hanging fruit from the outstanding tickets list Medium/Long Term ---------------- * Think more about the right set of states and transitions for comments and trackbacks (henceforth 'responses'). I'm pretty sure that the state machine for response publication isn't and shouldn't be the same as the machine for article publication. * Experiment with having multiple selectable state machines/publication policies for responses, so one policy might be 'open door' where everything gets published, another might throw all responses into a 'pending approval' queue, another may publishe all ajax comments and throw the rest into the pending approval queue or whatever. * A Bayesian trackback spam stopper * Make page caching work right. Back in 2.6.0 days, page caching was a huge pain in the bum, but by ghod Typo was fast when it was working. As I outlined in an earlier post, I think the Trigger system will allow us to get the benefits of future publication and expiring sidebars alongside the speed boost of page caching, but it's not straightforward. * Document our APIs. I've tended not to do much in the way of documentation because I'm far from sure that the APIs are stable enough for it not to be wasted effort. However, I'm starting to think that the new Sidebar API might stick around for a while and could use some documentation. (But I need to write a non-trivial sidebar to be sure of that I think...) * Give the Theming system a long, hard look. I'm inclined to adopt something like the Scribbish document structure -- having seen the kind of things that can be accomplished with CSS at the CSS Zen Garden[1] I want to make sure that our default markup is as friendly to that sort of modification as possible. Of course, there will always be a space for the kind of advanced themes that need to change the markup, and I want to make life easier for those too. I think there's a case for allowing themes to have parameters akin to sidebar parameters, but that needs some careful interface thought -- it shouldn't be impossible to hang theme parameters off the blog's settings though. * Blog settings need some thought too. If we do go all the way to multiblog capability (still open for debate), then we'll need to pull some settings out of the settings hash and up into the blogs table proper (at the very least we'll need to pull any settings that are used by the router to determine which blog a given url maps to up to the table so they can be accessed with a simple sql query). Also, it seems that the settings hash could benefit from being multilevel (one obvious case for this is in the default settings for various content objects, currently we have 'comment_default_allow_pings', 'article_default_allow_pings', 'article_default_allow_comments' and what have you. Wouldn't it be cool if you could do: Article.with_scope(:create => this_blog.defaults_for[Article]) do ... end Admittedly, it'd be cooler if you didn't have to do that, but could simply let this_blog.articles.build(...) handle it for you, but... baby steps... * Textfilters. I really, really, want to rework text filters so they're not controllers. * Er... * That's probably not all, but it'll do for now. Did I miss anything 1. http://www.csszengarden.com -- Piers Cawley <[EMAIL PROTECTED]> http://www.bofh.org.uk/ _______________________________________________ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list