Well, I Read up on Class::Accessor and Class::Delegation. The latter didn't seem particularly applicable to my situation, I took the time to look through Class::Accessor's source code. The way it sets accessors/mutators is actually quite similar to the technique I use for adding services that are just accessors.

So while it's nice to see that i was thinking along similar lines for that, the addServices provides for more than simple accessors/mutators, as it can be passed any subroutine reference to be installed as a class method, as well as any object which it will build an accessor for.

I'm also, after thinking on it some more, not so convinced that it's such a bad thing that the code really only addresses architecture. Because that was precisely my intention. It is up to the subclasses to use the architecture to accomplish something. As soon as i try to make the base class accomplish something beyond being a framework, i've made assumptions on how people want to use this code (much the same as how CGI::Application is primarily a frame work for the Run Mode paradigm, but integrates CGI.pm and HTML::Template as useful tools).

For an example of a module that 'does something', take a look at WWW::Pipeline::Example. I should note here that if you don't want to download the tarball, click on any documentation link and then change the .html to a .pm to see the original source.

As far as extensability metaphors go, I haven't thought of a better one than the concept of a Plugin as being a package that bundles services and handlers.

I hope this gives a bit more insight into the design decisions I've made so far.