dougm 01/05/30 15:48:19
Added: todo filters.txt
Log:
todo notes on filters
Revision Changes Path
1.1 modperl-2.0/todo/filters.txt
Index: filters.txt
===================================================================
direct C api mapping
--------------------
Apache::register_output_filter($filtername, $callback, $filter_type)
Apache::register_input_filter($filtername, $callback, $filter_type)
filter_type can be one of:
Apache::FTYPE_CONTENT
Apache::FTYPE_HTTP_HEADER
Apache::FTYPE_TRANSCODE
Apache::FTYPE_CONNECTION
Apache::FTYPE_NETWORK
$r->add_output_filter($name, $ctx)
$c->add_output_filter($name, $ctx)
$r->add_input_filter($name, $ctx)
$c->add_input_filter($name, $ctx)
note: $ctx will default to NULL
directives
----------
PerlInputFilterHandler
PerlOutputFilterHandler
each will be the equivalent of:
ap_register_{input,output}_filter($handler_name, $handler, $filter_type)
where:
$handler_name is the Perl name, at the moment is "MODPERL_OUTPUT" and
"MODPERL_INPUT", would be easy to switch that to the handler name
$handler is the modperl C callback
$filter_type defaults to AP_FTYPE_CONTENT, subroutine attributes can
be used to specify the filter_types list above
based on attributes, add_{input,output}_filter may need to happen at
different times, e.g. input filters who want to filter headers +
content vs. input filters who want to filter only content
alternative to those directives would be:
PerlInputFilter
PerlOutputFilter
combined with:
SetInputFilter
SetOutputFilter
pros: can use Perl{Input,Output}Filter to register the filter in
httpd.conf, rather than using the API. can then call
$r->add_{input,output}_filter($filter_name) at request time
cons: in the common case, requires two directives that use the same
values (the $handler_name)
- and/or -
PerlSetInputFilter
PerlSetOutputFilter
as aliases for SetInputFilter, SetOutputFilter which also take care of
filter registration (which PerlInputFilter, PerlOutputFilter would
have done)
pros: similar to Set{Input,Output}Filter
only need to use one directive
cons: the filter module needs to register the filter in order to add
the filter at request time without using a directive
however: PerlModule Apache::FooFilter
where Apache::FooFilter registers the filter, can provide this
functionality without requiring new Perl{Input,Output}Filter
directives
- in any case -
with the C api mapping it should be possible for a PerlModule to
register the filter(s), then use the standard Set{Input,Output}Filter
directives and the add_{input,output}_filter api at request time.
note: no need to maintain a list of PerlFilters (like PerlModule,
PerlRequire) since the directives trigger modperl_handler_new(), just
like all other Perl*Handlers
{get,set,push}_handlers
-----------------------
would be nice for Perl{Input,Output}FilterHandler to work with the
modperl {get,set,push}_handlers api just like other Perl*Handlers
tie handle interface
--------------------
both input/output filters should provide a tiehandle and/or perlio
interface.
Perl tiehandle methods include the following, '+' indicates must have, '-'
indicates not possible / doesn't make sense (though might require noop
stubs), '~' indicates would be nice if possible, '?' indicates unsure:
+ TIEHANDLE
+ PRINT
+ PRINTF
+ WRITE
+ READLINE
+ GETC
+ READ
+ CLOSE
? UNTIE
? DESTROY
+ BINMODE (noop)
? OPEN
~ EOF
- FILENO
~ SEEK
~ TELL
