Re: Ruby's Killer App - every language has one

Excellent! The feature set looks good. This may be the killer app.
mod_ruby needs to become standard too.

Just to clarify on these lines from you post:

Sasha wrote:
> It always leaves me completely baffled that there is not _one_ such 
> package for Ruby. But I don't exactly know what you mean by 
> architecture. I think you mean the way you can work with the product 
> (workflow)

By architecture I meant the framework that mambo developers use to
create new extensions to it. It is really easy to write a new "mambot"
that changes content. As an example, in mambo, if you place a php file
under the mabots directory, it automatically loaded and executed. A
content object is passed to it so that you can modify it before it
gets sent to browser. So for me it was very easy to write a content
"wikifier" because I didn't have to worry about anything else other
than writing the wikifier itself and of course, following their code
template to write a mambot. This is what I mean by architecture:
extensibility and cleanliness.

Here is something that I think mambo guys could have done better, and
it might be of your interest too. Some of the non-core
components/extensions that individuals write manage their content
their own way: with no framework hooking ability and in separate DB
tables. Then when somebody else like me writes a wikifier or a textile
markup we have no way of intercepting the content from their
components. As a result there are some wiki-enabled sections and
others that are not; there are sections of content like forums where
the markup syntax is different from the one of News; and when you
search with one search engine it only searches within one section. My
point is that a single abstraction/object that represents text content
could be used for any section and it could be stored in the same
location so that content modifers like wikifiers and markups can
change all content in the site (from news and forums and whatnot) by
using the same framework hook, and search engines could find any text
in the site by just querying one table (or one file). Furthermore,
this object needs to be fairly complete so taht indivdual developers
like me don't feel the need to hack DD tables or someone else's code
in order to add our functionality in it. Basically every operation to
retrieve and save (manage) any text content needs to be clearly
available through the object and proper framework hooks/callbacks.

Well, that's all. 

Good luck with your projects and have fun with CMS in Ruby. Do you
have a name for it yet?

Thanks,

Javier