perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: mod_include #perl support
Date Sun, 04 May 2003 01:27:01 GMT

> Yes, but you did *not* call a subrequest, so it makes it like "cgi" and 
> not "cmd". When you call a sub-request you get the previous data flushed.

that makes sense.  that also explains why I have to manually create a 
flush bucket to parse more than one tag per document.

>>> If so why don't you take the data from the tag create a bucket 
>>> brigade in the XS and pass it to the handler. In that case you will 
>>> allow to really have a filter. See what I mean? Parse the data as you 
>>> do now, but don't push it into args, instead create a new bb in C and 
>>> pass *it* to the handler in $bb.
>> hmm, yeah I can try that.
> I think this is very important, since if you do that, one doesn't have 
> to learn a new thing (assuming that they already know filters) and they 
> can use the streaming API instead of manipulating bucket brigades, which 
> makes it much simpler to understand. 

I tried doing that but I just kept getting segfaults.  I'll try again, 

the cool thing is that I now have working #perl sections as well as 
custom tag callbacks.  I'll try to put on the finishing touches over 
the next few weeks and make a preliminary release for folks to play with.

> And hey you don't even have to 
> parse the args, just put them all in one bucket and let the user do the 
> parsing.

yeah.  the problem is that I'm not sure how this all works in 
refcounting land, especially where interpreter pools come into play.

anyway, I have something in mind - once that is working fine we can 
tweak things a bit.

thanks for all your help so far :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message