On Thu, May 24, 2001 at 05:52:39PM -0700, Doug MacEachern wrote:
> let's consider everything before adding new code.
Ok :-). I have a reply in queue that works through your ideation w/
questions & suggestions. But first, let's look at really bifurcating
the API into a Perl*Filter API and a more Apache-esque API.
I'm starting to think that packaging low level Apache filters as though
they were Perl*Handlers is a misleading API: they're different from
plain handlers and treating them so is likely to mislead developers and
provides different semantics than the underlying Apache API provides,
leading to impedance mismatch in mod_perl's implementation and in
devloper's mental models.
Other handlers get called once per request or subrequest. Filters will
often get called 2 or many, many times (see any handler that skips
sending an EOS bucket, as well as mod_isapi and mod_proxy). Writing a
filter sub requires a much more event-driven mindest than writing a
handler sub: even the example reverse filter has a surprise in it waiting
for somebody that slaps it in front of mod_proxy or mod_isapi or any
other handler that sends multiple bbs of content.
Handler subs are simple use-once event handlers no intra-request state
needs to be kept. Filter subs will often need to be aware of BOS/EOS
state provided by mod_perl, and will also need to keep some
intra-request state.
So, how about two APIs?
API 1: Perl{In,Out}putFilterHandlers
Perl{In,Out}putFilter directives act much like todays, but use the
filter name when registering filters and AP_FTYPE_...CODE attrs to
modify when ap_add_xxx_filter()s get called. The only reason for using
the filter names is to enable debug dumps of the filter stack to be
read, and to obey the principle of "least surpise", meaning that there's
no need for the special-ness of MODPERL_{IN,OUT}PUT_FILTER_NAME to be
grokked by hapless mod_perl-internals-geek-wannabes like me.
However, to make these Perl{In,Out}putFilterHandlers consistent with
other Perl*Handlers, mod_perl would need
- to buffer all filter input in an ever-growing bucket brigade until
EOS is seen,
- then call the Perl*FilterHandler sub (once!),
- passing it $r blessed in to an Apache::RequestFilter (or some such)
class which would have alternative I/O subs that called the brigade
APIs. Would also provide a filter() accessor to get at the
"real" Apache::Filter object for the rare case when that might be
needed in sucha high level handler.
- and pass on the EOS when the sub exited.
The coding style would be very consistent with the existing mechanisms
and all the hairball stuff you can trip over with filters is balled up
into a tangle of wiring hidden behind nice, padded walls. No BOS/EOS
worries, not statefullness worries, just memory and (possibly) latency
worries.
The worries in that scheme, as well as the lack of flexibility in
calling ap_add_xxx_filter() need a low-level API to handle.
API 2: Bucket Brigade filters
No new directives.
The apache filters design assumes that admins will do a static link or a
LoadModule and the modules will then to ap_register_xxx_filter()
filters. What if mod_perl just went with the flow?
mod_perl could call ap_register_xxx_filter() on all subs compiled with
either an AP_FTYPE_FOO or a new MP_INPUT_FILTER or MP_OUTPUT_FILTER sub
attr. So you do a PerlSwitches -M or PerlModule or use/require them to
pull the thing in to memory and get them registered with apache. A
little finesse would be needed to not register the same sub twice.
Then you use any existing httpd config or API techniques to
ap_add_xxx_filter() them.
These low-level perl filters are different and will need some additional
explanation. Giving them a different configuration API makes it more
likely that said alternative emplanation will be noticed before buggy
code is written and the inevitable mailing list traffic ensues.
Pros:
- no new directives.
- no need for Perl coders to be aware of the registration mechanism,
just Set{In,Out}putHandler
- Works with / consistent with existing Apache infrastructure.
- API Clearly differentiated from Perl*Handlers, paralleling the way
that Perl filters are different from Perl*Handlers.
- much more powerful and fine-grained control possible.
Cons:
- Different from Perl*Handler API.
- Barrie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
