On Fri, 25 May 2001, barries wrote:
> Ok, I think I was underestimating how much padding you wanted on the
> direct C API mapping. I thought that that would be 0 padding (like how
> the ctx param to $r->add_output_filter() is treated).
i would like 0 padding for the 'direct' mapping. the padding aside from
Perl*FilterHandler's taking care of registration/adding is to provide the
stdio-like interface, $filter->{read,print,etc}. and maybe a bit more to
have an option where brigades are merged so a filter handler is only
called once per-request.
> So I was seeing three layers: Perl*FilterHandler-installed filters with
> lots of padding, The "Bucket Brigade" filters, with enough padding to
> make bucket brigade writing easy yet efficient (relative to
> Perl*FilterHandlers, anyway), and C level API, which is very low level
> and probably needs a little XS or Inline::C code to make much use of it.
> That's what I get for reading not-yet-polished code (the C level API)
> and assuming...
much of the brigade/bucket api has been polished, though there might be
some missing methods. its the registration/adding of filters thats not
really been touched yet.
> I think the main point of what I'm talking about here (the "Bucket
> Brigade filters") is to get enough padding and automation built in that
> it doesn't take any more Perl code to write them than it does to write
> Perl*Handlers, even though it's tricker code. I couldn't see how to add
> that level of padding to the C API without hiding the low level peices.
right, $filter->{read,print,etc} is attempting to hide the low level.
> Ok, now I see two alternatives: I'm saying use CODE attrs on subs you
> want auto-registered and call the C level ap_register_xxx_filter()
> wrapper if you want to register something manually, passing in the
> optional AP_FTYPE_FOO constant.
>
> You're saying to always use the ap_register_xxx_filter() manually all
> the time unless you use the Perl*FilterHandler directive. In this case
> the ap_register_xxx_filter() would need to arbitrate between any CODE
> attrs and whatever AP_FTYPE_FOO the user passed in (if they passed one
> in).
i suppose if no AP_FTYPE_ is passed to ap_register_xxx_filter(), mod_perl
could first look for sub attributes, if there are none, then default to
AP_FTYPE_CONTENT.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
