On Fri, 25 May 2001, barries wrote:
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.
to me, a Perl*Handler is just a configuration directive which specifies
the name of a Perl subroutine. and that subroutine is called during a
given apache plugin callback. all Perl*Handlers, including filters use
the same mechanism for resolving the name, loading the module if
needed, calling the subroutine, etc.
So, how about two APIs?
isn't this what i've been saying all along? :)
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.
sure, i'm all for using the Perl name to register the filter.
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!),
i would consider this as an option. it could actually be a standalone
filter module that collects all brigades into one before sending it
further down the chain. if its proven to be efficient, we can make it the
default.
- 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.
$filter-r gives you the request_rec. Perl*Handlers in 2.0 are passed
the same arguments as C handlers are passed.
- 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.
i hope we can get to that. the C bucket brigade api is klunky. the
$filter-{read,write} methods written as part of the padding, still need
to be implemented for input filters.
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
i think we're on the same page, this is pretty much the same as what
i outlined under 'direct C api mapping.
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.
except for this part. for the direct mapping, mod_perl should not do
anything special. it will be up to the Perl filter module to call
Apache::register_xxx_filter with AP_FTYPE_FOO. i'm ok with defaulting
arguments, e.g. ftype could default to AP_FTYPE_CONTENT.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
