> -----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.
>
> * 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 ;)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
