On Tue, 13 Dec 2005 09:17:18 -0500
Rob Kinyon <[EMAIL PROTECTED]> wrote:
> On 12/12/05, Michael Graham <[EMAIL PROTECTED]> wrote:
> > * Will this lead to more fragmentation of styles or greater
> > standardization?
>
> The question doesn't make sense because it doesn't matter. The point
> is that, just as Apache2 defined the 18 steps it takes in generating a
> response to a request, CA should define the N steps it takes to do its
> thing. Whether you choose to do the simple thing, the complicated
> thing, or the thing CA4 does ... that's your business. I see this as
> the true tinkertoy approach that CA initially held out to me.
Pluggability and modularaity is definitely an interesting aspect of the
C::A technology and community. It gives developers a lot of power. But
choice and flexibility can also lead to a proliferation of solutions,
which is why I asked the question.
For instance, if this approach would support multiple dispatch systems,
wouldn't that make it more likely that we'd see lots of competing
dispatch systems and we'll be less likely to seek consensus on some sort
of recommended approach?
But maybe proliferation of solutions is not so much of a problem if your
plugin system would also encourage or enforce standardization of
interfaces.
For instance, right now we have at least four Config plugins, each with
its own API.
Module Methods Single Param Access
------ ------- -------------------
CAP::Config::Simple config, config_param $self->config_param('foo')
CAP::ConfigAuto cfg $self->cfg('foo')
CAP::Config::YAML config_param $self->config_param('foo')
CAP::Config::Context conf $self->conf->param('foo')
If all these plugins could export a standard interface (without
trampling on each other's exported methods) then maybe proliferation of
Config plugins suddenly becomes a good thing because they are all
compatible with each other. This is the approach that OpenPlugin was
trying for, I believe. It's something I'd like to see addressed in
C::A, but I'm not convinced a ground-up rewrite is the solution :)
> > * Are there there specific things that are hard to do now that should
> > be easier, or is this more of a conceptual cleanup?
>
> This idea sprung out of the routes/dispatch discussion. If this were
> in place, the discussion wouldn't include "How do we hook this in?"
Hmmm. I didn't notice that part of the discussion :) It seemed to me
that when the discussion turned towards implementation, it was more
about coming up with the best API and dealing with backwards
compatibility of the API, not overcoming problems with the internals.
> > * How do subclasses work? When you've discovered which module is
> > going to handle a request, do you 'rebless' the current running
> > application into that module's namespace? Or does the dispatch
> > stuff happen at the class level before the app is run?
>
> Well, it currently happens in the run() method in CGI/Application.pm.
> I don't see any reason why the proposed steps-to-run would require any
> change other than where the code the fulfills that step lives.
But how would dispatch to a different module work? E.g.
my $app = My::Base::Class->new;
$app->dispatch(
TABLE => [
'blog' => { app => 'Blog' }
]
);
Assuming that 'Blog' is a subclass of 'My::Base::Class', how can $app
(which ISA 'My::Base::Class') dispatch to one of its own subclasses?
Would it create (and run) a new instance of $app? Or would it rebless
itself into the new package?
Michael
---
Michael Graham <[EMAIL PROTECTED]>
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
