Forum: Typo My Personal Medium/Long Term Typo goals

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-05-13 10:01
(Received via mailing list)
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
2763d87b1843f2d116e006b6039133a3?d=identicon&s=25 Frédéric de Villamil (Guest)
on 2006-05-13 11:42
(Received via mailing list)
Piers Cawley 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
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-05-13 13:15
(Received via mailing list)
Piers Cawley <pdcawley@bofh.org.uk> 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.
D6f24842b973de6cb75203c4c57dfbcb?d=identicon&s=25 Gary Shewan (Guest)
on 2006-05-13 15:26
(Received via mailing list)
On 13 May 2006, at 12:15, Piers Cawley 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
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-05-13 15:51
(Received via mailing list)
Gary Shewan <gpsnospam@gmail.com> 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.
5ce55767684e0cd1727db2b8b8975640?d=identicon&s=25 Steve Longdo (Guest)
on 2006-05-14 19:50
(Received via mailing list)
How will you handle having plugins register routes or are you
contemplating
making a 'typo plugin' versus the regular 'rails plugin'?
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-05-15 13:14
(Received via mailing list)
"Steve Longdo" <steve.longdo@gmail.com> 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.
This topic is locked and can not be replied to.