On Fri, May 25, 2001 at 11:06:47AM -0700, Doug MacEachern wrote: > > i think we're on the same page, this is pretty much the same as what > i outlined under 'direct C api mapping. 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). 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... 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. > > 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. 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). Either way seems pretty reasonable. It just seems like using the CODE attrs to trigger something automatic is fun & a nice level of helpful padding. When wouldn't you want it (seeing as you can always leave off the CODE attrs and pass the AP_FTYPE_FOO in to ap_register_xx_filter())? Thanks, Barrie --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
