On Fri, 30 Jul 2004, Joe Schaefer wrote:

> Nick Kew <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > > If there's a better approach, I'd be glad to update those docs.
> >
> > Wouldn't an ap_hook_insert_filter() handler be the ideal spot for
> > that?
>
> I thought such hooks were run on *every* request, not
> just the ones which require a particular output filter?
> If so, for performance reasons that's not a suitable
> solution for folks writing output filters with mod_perl.

Fair enough.  So we have a reason not to dispense with that
handler.  It just means we need to document when not to use it.

So the next question is, is it sufficient to maintain the two
APIs (the established 2.0 + my proposal)?  I'm thinking about that
one: it's not really a problem to provide a combined API if there's
anything to gain by it.  But in any case, you can rest assured I'm
not suggesting we abolish the old API :-)  A filter can register
itself as an output filter (old API) and as a smart filter provider
(new API).

Unless of course someone can radically improve on my proposals ...

-- 
Nick Kew

Reply via email to