[typo] More medium/long term Typo goals

Piers Cawley pdcawley at bofh.org.uk
Tue Aug 1 05:07:09 EDT 2006

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>

More information about the Typo-list mailing list