Re: rfc: new filtering APIs
Geoffrey Young wrote:
[...]
I don't think that's how it'll work. I was thinking of having a
subroutine with a special attribute. So after the module has been
compiled we can walk through all the CODE entries and check whether
any of them is having the FilterInitHandler attribute and take it from
there. Does this sound good?
you mean something like
sub my_update_mtime : filter_init {};
?
Yes.
I guess that's ok. it really depends on how the other interfaces work.
I like the streaming filter API, and wouldn't want to deviate too far
from that model to get this to work. and $filter->init (or whatever) is
a bit more like the other calls.
But the $filter object doesn't exist till it was called by Apache, it's
created dynamically when Apache calls the filter. So I'm not sure where
you want to call $filter->init(). If this can be done in the first filter
invocation, like I've suggested in my first reply using the ctx flag, than
you have this feature already. Please try it and let us know if it does
what you want.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: rfc: new filtering APIs
Stas Bekman wrote:
Geoffrey Young wrote:
I would want at least a real-time interface for this, something
similar to
$filter->init(sub {shift->update_mtime($package_mtime)} );
where would you run this code?
outsite of a handler() subroutine, pretty much like I showed it - on
module load. I suspect you'd have to register the init handler that
way for a few reasons, namely that you'd miss the first request if you
waited until after default_handler runs to register your init filter.
it's also good to do it outside of handler() to handle stuff like
reloads, where the init routine might use a closure to avoid
recalculating the package mtime on each request.
The problem is that currently the resolving (read: module compiling and
handler resolving) is postponed till the first invocation of the handler
unless the module was manually preloaded or PerlOptions +Autoload was set.
I suppose that this could be a documented thing. e.g.:
if you use filter_init, you must preload the module at the server startup.
that sounds reasonable. preloading is always a good idea anyway.
I'm not sure what that means for actually getting at the filter object
outside of a request :)
I don't think that's how it'll work. I was thinking of having a
subroutine with a special attribute. So after the module has been
compiled we can walk through all the CODE entries and check whether any
of them is having the FilterInitHandler attribute and take it from
there. Does this sound good?
you mean something like
sub my_update_mtime : filter_init {};
?
I guess that's ok. it really depends on how the other interfaces
work. I like the streaming filter API, and wouldn't want to deviate
too far from that model to get this to work. and $filter->init (or
whatever) is a bit more like the other calls.
but you're in a better position to judge how this should/needs to
work. besides, once the hooks are there, we can probably make it look
however we want.
I read the thread at the URL you've provided. The latest comment from
Dec says that the bug is still there. So I suppose that the feature was
added but not really used so far. I could be wrong.
I'll try to look into this a bit more next week.
Cool. Thanks Geoff!
:)
--Geoff
Re: rfc: new filtering APIs
Geoffrey Young wrote:
I would want at least a real-time interface for this, something
similar to
$filter->init(sub {shift->update_mtime($package_mtime)} );
where would you run this code?
outsite of a handler() subroutine, pretty much like I showed it - on
module load. I suspect you'd have to register the init handler that way
for a few reasons, namely that you'd miss the first request if you
waited until after default_handler runs to register your init filter.
it's also good to do it outside of handler() to handle stuff like
reloads, where the init routine might use a closure to avoid
recalculating the package mtime on each request.
The problem is that currently the resolving (read: module compiling and
handler resolving) is postponed till the first invocation of the handler
unless the module was manually preloaded or PerlOptions +Autoload was set.
I suppose that this could be a documented thing. e.g.:
if you use filter_init, you must preload the module at the server startup.
I'm not sure what that means for actually getting at the filter object
outside of a request :)
I don't think that's how it'll work. I was thinking of having a subroutine
with a special attribute. So after the module has been compiled we can
walk through all the CODE entries and check whether any of them is having
the FilterInitHandler attribute and take it from there. Does this sound good?
if you come up with the interface, I'll write the tests to make sure
it does what we need.
Cool.
Is there some C module that uses that hook so I can look at it? I
guess somewhere in PHP, because I don't seem to see any in the core
modules.
yeah, the bug report points to PHP. it also mentions mod_include, but I
haven't looked at it yet.
I read the thread at the URL you've provided. The latest comment from Dec
says that the bug is still there. So I suppose that the feature was added
but not really used so far. I could be wrong.
I'll try to look into this a bit more next week.
Cool. Thanks Geoff!
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: rfc: new filtering APIs
I would want at least a real-time interface for this, something
similar to
$filter->init(sub {shift->update_mtime($package_mtime)} );
where would you run this code?
outsite of a handler() subroutine, pretty much like I showed it - on
module load. I suspect you'd have to register the init handler that
way for a few reasons, namely that you'd miss the first request if you
waited until after default_handler runs to register your init filter.
it's also good to do it outside of handler() to handle stuff like
reloads, where the init routine might use a closure to avoid
recalculating the package mtime on each request.
I'm not sure what that means for actually getting at the filter object
outside of a request :)
[snip]
if you come up with the interface, I'll write the tests to make sure
it does what we need.
Cool.
Is there some C module that uses that hook so I can look at it? I guess
somewhere in PHP, because I don't seem to see any in the core modules.
yeah, the bug report points to PHP. it also mentions mod_include, but
I haven't looked at it yet.
I'll try to look into this a bit more next week.
--Geoff
Re: rfc: new filtering APIs
Geoffrey Young wrote:
[...]
no, you need the real filter_init hook.
the issue here is that default_handler has meets_condiditions() logic in
it, so it makes decisions about whether or not to send content down the
chain. this is generally bad for filters, since they may have their own
criteria for determining what gets involved in making that decision - if
default-handler doesn't have all the information, it can return
NOT_MODIFIED when the filter would have chosen to re-modify the content
(based on, say, the fact that the version of the code has changed so it
does things differently now).
filter_init is a hook that runs code before any handlers run, I suspect
for adding calls to update_mtime() and other similar things.
ok
I agree that having a dedicated filter_init seems to be cleaner and
probably more efficient.
If filter_init is wanted, how should it be set by the Perl code? Using
an optional second argument to the filter configuration?
PerlOutputFilterHandler MyFilter MyFilter::init
I would want at least a real-time interface for this, something similar to
$filter->init(sub {shift->update_mtime($package_mtime)} );
where would you run this code?
sub handler {
...
}
it's important that the filter be able to insert this logic itself
without relying on httpd.conf stuff. that makes the filter
self-contained and a bit more DWIMmy. of course, the subroutine/coderef
would have to run on each request, similar to $r->register_cleanup, just
at the other end.
Obviously for each conf option there should be a perl interface
(add/remove filters pending)
Also can you please give me some useful test I can play with? Probably
one of the examples from your book will do ;)
I'm working on something now, but without a tie into filter_init there's
not much to show :)
if you come up with the interface, I'll write the tests to make sure it
does what we need.
Cool.
Is there some C module that uses that hook so I can look at it? I guess
somewhere in PHP, because I don't seem to see any in the core modules.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: rfc: new filtering APIs
Stas Bekman wrote:
Geoffrey Young wrote:
Finally, other than add/remove filters APIs which we have talked
about, what other APIs do you want for filters?
is there an interface to filter_init?
see the discussion on
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9673
or CHANGES file for a description of why it was added.
this API may be crucial to mod_perl developers who want to handle
conditional GET requests properly with their filters.
First of all you can always do:
unless ($filter->ctx) {
# filter is called for the first time
# and this code won't be run only once
$filter->ctx(1);
}
so if you want to do something once, or e.g. remove yourself you can do
it in this block. So it seems to be similar to filter_init. Or am I
wrong here?
no, you need the real filter_init hook.
the issue here is that default_handler has meets_condiditions() logic in it,
so it makes decisions about whether or not to send content down the chain.
this is generally bad for filters, since they may have their own criteria
for determining what gets involved in making that decision - if
default-handler doesn't have all the information, it can return NOT_MODIFIED
when the filter would have chosen to re-modify the content (based on, say,
the fact that the version of the code has changed so it does things
differently now).
filter_init is a hook that runs code before any handlers run, I suspect for
adding calls to update_mtime() and other similar things.
I agree that having a dedicated filter_init seems to be
cleaner and probably more efficient.
If filter_init is wanted, how should it be set by the Perl code? Using
an optional second argument to the filter configuration?
PerlOutputFilterHandler MyFilter MyFilter::init
I would want at least a real-time interface for this, something similar to
$filter->init(sub {shift->update_mtime($package_mtime)} );
sub handler {
...
}
it's important that the filter be able to insert this logic itself without
relying on httpd.conf stuff. that makes the filter self-contained and a bit
more DWIMmy. of course, the subroutine/coderef would have to run on each
request, similar to $r->register_cleanup, just at the other end.
Also can you please give me some useful test I can play with? Probably
one of the examples from your book will do ;)
I'm working on something now, but without a tie into filter_init there's not
much to show :)
if you come up with the interface, I'll write the tests to make sure it does
what we need.
--Geoff
Re: rfc: new filtering APIs
Geoffrey Young wrote:
Finally, other than add/remove filters APIs which we have talked
about, what other APIs do you want for filters?
is there an interface to filter_init?
see the discussion on
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9673
or CHANGES file for a description of why it was added.
this API may be crucial to mod_perl developers who want to handle
conditional GET requests properly with their filters.
First of all you can always do:
unless ($filter->ctx) {
# filter is called for the first time
# and this code won't be run only once
$filter->ctx(1);
}
so if you want to do something once, or e.g. remove yourself you can do it
in this block. So it seems to be similar to filter_init. Or am I wrong
here? I agree that having a dedicated filter_init seems to be cleaner and
probably more efficient.
If filter_init is wanted, how should it be set by the Perl code? Using an
optional second argument to the filter configuration?
PerlOutputFilterHandler MyFilter MyFilter::init
Also can you please give me some useful test I can play with? Probably one
of the examples from your book will do ;)
Thanks Geoff.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: rfc: new filtering APIs
Finally, other than add/remove filters APIs which we have talked about, what other APIs do you want for filters? is there an interface to filter_init? see the discussion on http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9673 or CHANGES file for a description of why it was added. this API may be crucial to mod_perl developers who want to handle conditional GET requests properly with their filters. --Geoff
