On Fri, May 25, 2001 at 03:52:31PM -0700, Doug MacEachern wrote:
> On Fri, 25 May 2001, barries wrote:
>
> > We're on the same page, but right now $ctx in the $r->add_xxx_filter(
> > "foo", $ctx) is written to the f->ctx field that the modperl_filter_t
> > comes to reside in. So I'm proposing a perl_ctx in the modperl_filter_t
> > to carry Perl context and mapping the $ctx in that call to
> > (modperl_filter_t *f->ctx)->perl_ctx
>
> right, there is a slot already reserved for that:
> typedef struct {
> --->SV *data;
Yeah, figured that's what data was for.
> > s/is_eos()/eof()/ then. And s/is_BOS()/!tell()/ for that matter. Can't
> > really have seek(), since you might be on the 5th of 10 brigades, with
> > the first four already send downstream.
>
> right, unless we have the module in the middle that collects all the
> brigades into one.
Yup.
> the Perl-level context (set with ${r,c}->add_xxx_filter) should live in
> modperl_filter_ctx_t.data, would be find to rename data perl_ctx or
> whatever.
> not sure what you mean by Apache::ap_add_filter ... C pointer part ?
Well, if you call
Apache::ap_add_output_filter( "foo", AP_FTYPE_CONTENT, $ctx )
where Foo is not related to mod_perl, you better be passing an integer
in $ctx which is a pointer to some C struct you cooked up in XS that
filter foo is expecting. This would allow mod_perl interfaces to C
level filters.
- Barrie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
