[Catmail] Making it pluggable

[Jose Luis Martinez]

Hi,

	Pluggability should be built into catmail. I think that a pluggable app 
should have pluggability as a core feature, and not just a set of 
callbacks, or points where plugins should be called, because the 
developers will never get right where people want to plug in or change 
the default behaviour.

	I've taken a look at Catalyst::Plugin::Pluggable. A couple of things 
don't quite hit MY sweet spot:

	1- the developers have to call forward_all explicitly in the places 
they think people will plug in.
	2- the order of the plugins called is by alfabetic order (ok, ok, you 
can change that...). If they are sorted by name, you would get people 
naming their plugin in f(x) of the order they want them called (ugly, 
and bad for interdependant plugins). You can sort by a numeric "plugin 
order" class attribute, but in the long term I think it wouldn't be 
maintainable. Normally plugin order is important because you want your 
plugin executed before another one, because you are dependant on what it 
does.
	3- I don't quite like the way of "hooking in" (all actions with a 
specific name will be called).

	Does anyone know of another way to make a Cat app pluggable? I do have 
a couple of ideas for a Catalyst Plugin module that would permit 
pluggability addressing the issues I've just exposed:

You just write your Cat app the way you normally would, then enable the 
Pluggability plugin, pulling in all modules beneath a determined 
namespace (CatMail::Plugin for the sake of the example). The plugins 
should be something like:

package CatMail::Plugin::MySuperPlugin;

sub do_something : PluginBefore('/an/action') {
   my ($self, $c) = @_;
   ...
}

sub do_another_thing : PluginAfter('/a/second/action') {
   my ($self, $c) = @_;
   ...
}

1;

When a controller matches '/an/action', 
CatMail::Plugin::MySuperPlugin->do_something would be called. Two plugin 
methods matching the same action would be called in undefined order, 
except if a dependency between them is established. If MySuperPlugin2 
declares a dependency on MySuperPlugin1, then the matching plugin 
actions for MySuperPlugin2 would always be called before the matching 
actions of MySuperPlugin1.

It looks like Local, RegEx and other plugin actions would have to be 
developed for completeness. So you would have PluginBeforeLocal, 
PluginAfterRegEx, etc. Maybe the Cat ones could somehow be used so the 
pluggability plugin would not have to maintain separate versions.

Am I over-engineering? Am I missing some other clever way(s) of doing 
what I pretend? Should I start building it?

Best Regards,

Jose Luis Martinez
jlmartinez at capside.com