My Personal Medium/Long Term Typo goals


#1

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

#2

Piers C. a écrit :

on the Content object
be the same as the machine for article publication.

  • Make page caching work right. Back in 2.6.0 days, page caching was a
    could use some documentation. (But I need to write a non-trivial
    easier for those too. I think there’s a case for allowing themes to
    query). Also, it seems that the settings hash could benefit from
    Admittedly, it’d be cooler if you didn’t have to do that, but could
  1. http://www.csszengarden.com

Hi list,

I come from the Wordpress world where I’ve developped some themes and
plugins.

For the spam thing, we have a very powerfull engine made of several
plugins called Spam Karma. The code is pretty neat, and I don’t think it
would be difficult to port it in Ruby.

With all the filters, there is also a centralized blacklist database
that can be used as well.

Spam Karma code is avaliable at
http://unknowngenius.com/blog/wordpress/spam-karma/

Regards,
Frederic


#3

Piers C. removed_email_address@domain.invalid writes:

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.

[…]

Medium/Long Term

[…]

  • 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

Yes, it seems I did:

  • Admin plugins. Rework the admin interface so it’s easy to add a new
    admin tab as a plugin. That way we can experiment with things like
    spam handling/blacklisting or whatever in a way that’s (hopefully)
    decoupled from the rest of the administrative interface. It would
    also be good to be able to add actions to existing tabs in a neat
    fashion. Things like the podcasting addons have the potential to
    work rather neatly as a plugin

  • ‘Whole body’ plugins. Thinking about the possibility of making the
    podcasting addons into an admin plugin, it occurs that really it
    would need to be more than that because there’s also user visible
    feeds to worry about. It seems there’s a case for at least working
    out a standard directory structure and registration system for
    plugins so that they can integrate themselves with the wider Typo
    system.


#4

Gary S. removed_email_address@domain.invalid writes:

  • ‘Whole body’ plugins. Thinking about the possibility of making the
    podcasting addons into an admin plugin, it occurs that really it
    would need to be more than that because there’s also user visible
    feeds to worry about. It seems there’s a case for at least working
    out a standard directory structure and registration system for
    plugins so that they can integrate themselves with the wider Typo
    system.

Now that’s an exciting concept … you read my mind because I’d just
asked myself “What about a plugin architecture?”

Heh. I’ve got the idea in my head now. I dunno when I’ll do something
about it, but once something is named it’s much easier to work on it
unconsciously.


#5

How will you handle having plugins register routes or are you
contemplating
making a ‘typo plugin’ versus the regular ‘rails plugin’?


#6

On 13 May 2006, at 12:15, Piers C. wrote:

podcasting addons into an admin plugin, it occurs that really it
would need to be more than that because there’s also user visible
feeds to worry about. It seems there’s a case for at least working
out a standard directory structure and registration system for
plugins so that they can integrate themselves with the wider Typo
system.

Now that’s an exciting concept … you read my mind because I’d just
asked myself “What about a plugin architecture?”

Gary


#7

“Steve L.” removed_email_address@domain.invalid writes:

How will you handle having plugins register routes or are you contemplating
making a ‘typo plugin’ versus the regular ‘rails plugin’?

Dunno yet. Plugins are definitely in the ‘blue sky’ phase of planning
at the moment.