I'm trying to write a plugin that wants to choose an alternate way of servin
g a file
from a web service, but only depending on the presence on something in the f
ilesystem.

This means that the eg start_serve_request may need to do io before it can
take the decision as to whether to take over the request. But this io should
 (of course)
be asynchronous. Unfortunately, the existing hooks expect a direct return 0 
or 1, instead
of a later continuation with the decision.

It occurs to be that perhaps 'morally' all hooks should in fact pass in cont
inuations,
instead of expecting return values. This would be quite easy to maintain bac
kward compatibility
with the old hook API, by adding new add-a-hook functions and keeping the ol
d ones as wrappers.

Has anyone already done this?

Would it be a good idea? What about performance of creating PERL continuatio
ns?

Any other solutions to the problem?

Is it generally accepted at perlbal's current level of development to just a
dd in additional hook
functionality that is missing, or are there particular reasons or vested int
erests in the absence of some things?

If I didn't go the whole hog of splitting all the hooks, I'd need to split u
p serve_request
to gain access to the middle entry point of it after the async IO with the r
eplacement file name.

Thanks in advance for any help, and thanks for perlbal!

--
Brian_Brunswick__bdb@forbidden.co. uk__Video_Software_Architect____Disclaim
er

[ Post a follow-up to this message ]

This is the direction we took with DJabberd, our XMPP/Jabber server, but
Perlbal still has a lot of legacy hook-must-return-a-value-now stuff.

Non-intrusive patches welcome.  Perhaps a parallel hook with different
semantics, keeping the existing one(s) unchanged?


On Mon, 5 Mar 2007, Brian Brunswick wrote:

> I'm trying to write a plugin that wants to choose an alternate way of serv
ing a file
> from a web service, but only depending on the presence on something in the
 filesystem.
>
> This means that the eg start_serve_request may need to do io before it can
> take the decision as to whether to take over the request. But this io shou
ld (of course)
> be asynchronous. Unfortunately, the existing hooks expect a direct return 
0 or 1, instead
> of a later continuation with the decision.
>
> It occurs to be that perhaps 'morally' all hooks should in fact pass in co
ntinuations,
> instead of expecting return values. This would be quite easy to maintain b
ackward compatibility
> with the old hook API, by adding new add-a-hook functions and keeping the 
old ones as wrappers.
>
> Has anyone already done this?
>
> Would it be a good idea? What about performance of creating PERL continuat
ions?
>
> Any other solutions to the problem?
>
> Is it generally accepted at perlbal's current level of development to just
 add in additional hook
> functionality that is missing, or are there particular reasons or vested i
nterests in the absence of some things?
>
> If I didn't go the whole hog of splitting all the hooks, I'd need to split
 up serve_request
> to gain access to the middle entry point of it after the async IO with the
 replacement file name.
>
> Thanks in advance for any help, and thanks for perlbal!
>
> --
> Brian_Brunswick__bdb@forbidden.co. uk__Video_Software_Architect____Disclaim

er
>
>

[ Post a follow-up to this message ]