>-----Original Message-----
>From: Doug MacEachern
>To: Geoffrey Young
>Cc: '[EMAIL PROTECTED]'
>Sent: 7/16/01 8:53 PM
>Subject: Re: directive handlers in 2.0
>
>On Mon, 16 Jul 2001, Geoffrey Young wrote:
>
>> hi doug...
>> 
>>   what's the game plan for directive handlers in 2.0.  I was playing
>around
>> with them in 1.3 quite heavily last week and found myself wondering if
>it
>> wouldn't be cool to have a generic mechanism that you could slip into
>the
>> module record that would allow you to dispense with the Perl*Handler
>line
>> (if you wanted to).  doesn't seem that hard if you plan for it, though
>it'd
>> be a kludge to get it into 1.3 it looks like.
>> 
>> not much of a gain, but pretty cool for transparently overriding core
>> directives, since you currently need 3 directives (PerlModule,
>Perl*Handler,
>> Directive) to override a C module and have to remember to put the
>> Perl*Handler everywhere you will need it.
>
>in 1.x you can already do this:
>
>push @Apache::ReadConfig::Perl*Handler, 'Apache::Foo';

right - that's exactly what I did for that Apache::ReverseLocation example a
few months ago.  the problem I had with that, though, was that I assummed
you had to be rather sophisticated in how you approach the
Apache::ReadConfig namespace (determine if you are in a vhost, in a
container, will conflict with other <Perl> sections, etc).  I ended up just
doing things on a per-server level and a bit of mapping, since it was
proof-of-concept, and didn't investigate whether this was true or not...


>2.0 will probably have something like register_hooks for Perl too.
>
>thing is, i think using directives to configure perl modules is better
>than having the modules always be called for a given hook.  by forcing
>them to be configured in httpd.conf, chances are they will be called
>less,
>rather than always called and return DECLINED if they are not enabled
>some
>other way. the fewer calls into the perl runtime we make, the better the
>server will perform.

right, but consider this - Randy and I just came up with a solution for the
book that lets XBitHack be meaningful for Win32.  you can implement it all
by itself, which is nice.  you can override XBitHack, which is nicer, but
you need a PerlFixupHandler in any event.  in this case, though, we never
intend a DECLINED - our XBitHack should always replace the mod_include
directive.

My thought was that, since you are already implementing directive handlers,
register it with the fixup phase when you generate the XS (or whatever, as
you pointed out in the other reply).  This way the only change to httpd.conf
is a single "PerlModule Foo" and XBitHack works as it always did, merges and
all, only with our improved version - and you don't have to remember to put
the PerlFixupHandler everywhere you put XBitHack.

but maybe I'm overanalyzing things :)

--Geoff

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to