Re: proposal for filter_init implementation (was: Re: rfc: new filtering APIs)

Geoffrey Young wrote:
> Stas Bekman wrote:
>
> > As we now have most of filtering API completed, it's time to finish 
> > off the filter_init API. 
>
>
> :)
>
> > Here is a proposal for filter_init implementation:
> >
> > Extend the struct modperl_filter_ctx_t, to include:
> >
> >   int init_done;
> >   modperl_handle_t *init_handler;
> >
> > now we can register a new sub-routine to perform init for a given
> > filter and have a flag to make sure that this is done once.
>
>
> cool.  does this mean that the code will be available (somehow) via 
> $f->ctx?  I think that maybe there might be value in being able to do
>
> $f->ctx->{init}->();
>
> someday :)

Why complicating things. If you assign an init sub it's always run once before 
the filter is invoked for the first time. You don't invoke it by yourself.

But if you want to, you don't have to use an init mechanism (once it's added 
and simply do:

sub my_init {}

sub my_filter {
  unless ($f->ctx->{init_done}) {
      my_init();
      $f->ctx->{init_done}++;
  }
}

That's exactly why I was asking you, whether we really need the filter init 
mechanism, since it's so easy to implement it when you need it.

[...]
> > sub handler : FilterRequestHandler FilterInitHandler('my_init') {}
> >
> > even if this works, we probably might have issues with resolving 
> > 'my_init' and anonymous callbacks won't be possible.
>
>
> well, personally I like this approach the best I think.  at the very 
> least, we need this (in addition to other approaches) in order to allow 
> module writers to make init routines mandatory (see below).

Mandatory? Why in the world do you want to make them mandatory?

> as for anonymous subs, we won't be able to use them now or ever?   I 
> know there are some incomplete issues with using anonymous subs in 
> certain areas (such as inlined in httpd.conf) but I was assuming that 
> they would be non-issues eventually.

Now with handlers. You can certainly push (once anon handlers are supported)

$r->add_input_filter(sub {...});

As for attributes I simply don't know how would you go about doing:

sub handler : FilterRequestHandler FilterInitHandler( sub {...} ) {}

I'm not sure whether this works:

$r->add_input_filter(sub FilterInitHandler( sub {...} ) {...} );

> > 2) Another alternative is to change the way PerlInputFilterHandler is
> > configured and let it be TAKE12 instead of ITERATE and then you can 
> > just say:
> >
> > PerlInputFilterHandler handler [init_handler]
> >
> > but then filter handlers will differ from other handlers. I don't know
> > if it's a good thing or not. But it's certainly the simplest solution.
>
>
> I don't think this is bad per se, but it cannot be othe only way.  as 
> I've said before, the init handler will be an integral part of the 
> filter itself - in most cases you will not want to separate it from the 
> module, since you will need it in order for the module to function 
> properly (think managing conditional GETs).  so, asking module users to 
> do more than
>
> PerlOutputFilterHandler My::Filter
>
> seems excessive from an EU standpoint for modules that require the hook 
> - it should be transparent.  it also suggests that the [init_handler] is 
> optional where it may not be for a given module.

I see what you mean. But that depends on whether the attributes approach will 
really work. I'll give it a try today.

I still think that most filters will have no init handler. I haven't seen the 
promised arguments of why do you think it should be mandatory.

> the flip side of this is that if you give the module writer no interface 
> to filter_init (such as solution #1) then module writers have no way to 
> make the init routine required.  yucko.

Eh? But both give you an interface to filter_init, I don't follow you.

> > The perl API is easy, just change:
> >
> > void mpxs_Apache__RequestRec_add_input_filter(pTHX_ request_rec *r,
> >                                               SV *callback)
> >
> > to:
> >
> > void mpxs_Apache__RequestRec_add_input_filter(pTHX_ request_rec *r,
> >                                               SV *callback, SV 
> > *init_callback)
>
>
> as an aside, is there any reason you keep using input filters as the 
> example?  I haven't looked over the input filter design as much as with 
> output filters, but filter_init was added specifically for handling 
> conditional GET requests with output filters - I'm not sure what value 
> there is for input filters, or even if the input filter Apache mechanism 
> supports it.  but if it does, cool :)

No special reason at all. It was just copy-n-paste and I guess the editor was 
showing the input filters at that moment.

You may want to run filter_init for input filters to initialize the filter, 
unless you use the technique with $f->ctx, which seems just fine to me.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@xxxxxxxxxx http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com