> > -----Original Message-----
> > From: Stas Bekman [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, September 07, 2001 4:57 AM
> > To: modperl-2.0 dev-list
> > Subject: RFC: Apache::Registry family re-design
> >
> >
> > This is a proposal paper for Apache::Registry for mod_perl 2.0.
> >
> > The whole family of Apache::Registry-like modules can be transformed
> > from hardcoded packages with specified functionality into a what I
> > call Apache::Registry::Cooker packages.
> >
> > Since various users will want various behavior from various registry
> > modules, it'll be too cumbersome to create and maintain all possible
> > variations. Of course this could be implemented as a sub-classable
> > system, where users wishing their own behavior, need to subclass
> > whichever existing module whose behavior is the closest to the desired
> > one. I believe that compiling the registry package on the fly will
> > make things more flexible.
> >
> > So I suggest the following spec:
> >
> > Apache::Registry::Cooker - cook the desired registry handler.
> >
> > e.g. put in startup.pl:
> >
> > use Apache::Registry::Cooker;
> > Apache::Registry::Cooker::cook
> > ({
> > package => 'MyCoolRegistry',
> > key_alg => 'filename', # (or inode, or uri, or vh+uri, ...)
> > stat_src => 1, (0 not to stat on each request)
> > flush => 0, # flush namespace on each request
> > ... # more features to come
> > });
>
> hmmm... I'm not sure what to think about this. my first thought was "hey,
> that's pretty cool" after which I found myself asking if it is really wise
> to deviate from an OO, subclassable design here. I mean, flags are nice to
> toggle behavior like the stat() calls, but I'd really want to see some
> benchmarks against the two designs (at the proof-of-concept stage, at least)
> before lots of effort went into something like this. Especially since most
> people would just be using the stock Registry, so I wouldn't want to slow
> that down just because 'stat_src => 1' is more convenient than overriding a
> do_stat() for those few shops that need a custom version of the code.
May be I didn't complete my thoughts in words, but that the whole point of
my idea: make the interface as flexible as possible, now the
implementation is up to us, nothing prevents us from using OO and
subclasses. It's just that you don't have hardcoded subclasses, you write
the subclassing on the fly.
On the other hand, why do you think that would be slower? On the opposite,
the non-subclassed approach will be faster as there is no search for
methods in @ISA, all the methods are on the surface. We can go even
further and use attributes to resolve the methods lookup at compile time.
If you know that most people will use stock Registry, why wasting cycles
on constant resolving of subclassing.
Another benefit I'm trying to reap is to move to constants, and make them
set-able from the user space. Especially for debugging.
The mechanism I suggest is simple:
tell me which components do you want and I'll cook the package for you and
compile it for you. Now you have a package like it was a real file on the
disk, but you don't have to create any files ahead.
And as I've mentioned in this doc, if you want the old behavior just write
wrappers which request the same features, previously were in effect.
> > * global variables persistance: I suggest to have the cooker option to
> > flash only globals at the end of each request.
>
> beware of those flashing globals ;)
flushing, blushing :)
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
