Zed, that change will require rewrite of mongrel_rails and
mongrel_rails_service.
With this we are planning do a mongrel_service as we talk before?
In that case, we will jump the handlers and filters into the mongrel
core instead?
Maybe 0.4.0 will be more appropiate.
Let me know when changes are ready so I check out and update the
scripts according the new plugin system.
Luis
On 2/28/06, Zed Shaw <zedshaw at zedshaw.com>
wrote:> Hi Everyone,
>
> Just a quick message to say that I''m holding back the 0.3.7
release so I can
> get this flexible plugin system going that we''ll need for the next
step of
> loading user defined handlers and filters.
>
> What I''ve done is completely replaces pluginfactory with an
alternative that
> lets you create simple classes like so:
>
> class Stop < Plugin "/commands"
> ...
> end
>
> And it''ll get registered automagically into the PluginManager. I
have the
> command system already doing this without problems and it is a lot faster
> than Plugin factory. The weird class definition syntax is a strange trick
I
> picked up from the Camping folks and basically means that this plugin
> belongs in the "/commands" category. These categories can be
fairly
> arbitrary and are really just using the URIClassifier.
>
> So, how will it get used? I''m adding an option -L that you can
pass a path
> and Mongrel will load all the .rb files in that directory for you. All you
> then need to do is place your new commands (or other plugins) in this
> directory however you want and they''ll be available.
>
> I''m going to then work out how you would create your own handlers
from this,
> and finally add filters and loading those arbitrarily as well.
>
> Anyway, should have this into svn tonight so please test away and report
the
> breakage to me.
>
> Zed
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>