On Fri, 30 Jul 2004, Joe Schaefer wrote: > Nick Kew <[EMAIL PROTECTED]> writes: > > [...] > > > (2) I propose getting rid of it because I cannot see any circumstance > > in which it's necessary in an output filter. > > But you still need a simple way for an output filter to run some code > before the content handler gets invoked.
Fair enough. Then you register it unconditionally using the old API. > FWIW I've been advising output > filter authors that want to get at libapreq2's post data to use > filter_init for that: > > http://cvs.apache.org/~joes/libapreq2-2.04-dev/docs/html/apreq_faq.html > > 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? But anyway, if there is a valid need for filter_init in its present form in some output filters, we can still use it, provided we document why it might be inefficient to use it with dynamic configuration. -- Nick Kew
