Cliff Woolley wrote:
On Wed, 19 May 2004, Cliff Woolley wrote:


can't just ignore APR_ENOTIMPL for bucket types, because pipe and socket
buckets never had setaside implemented on them.  I thought I remembered
that that was because Greg and Ryan and I had some huge debate about it
and it was decided for some reason that setting aside a pipe or socket
didn't make sense.  But now I can't find where we talked about that in the
archives.


BTW - I remembered the reason why it was decided that it didn't make sense
to implement setaside for pipe/socket buckets.  It's because for all other
bucket types, setaside takes one bucket in and produces one bucket out,
whereas for pipes and sockets it would take one bucket in and either
produce one bucket if the lifetime request was already satisfied or it
would produce a chain of n buckets out where n is proportional to the size
of the data that had been waiting around to be read in the pipe/socket.
It was that inconsistency that was disliked.  At this point, I'm willing
to agree to whatever makes things work and would probably accept this
inconsistency as long as it's documented.  What we have now is bug-prone
beyond belief.

And a lot of pain and wasted time could be saved if all this was documented. I'm not aware of such documentation's existance, besides very scarce notes in the header files. Filters are a very complex area, and w/o proper user docs it's no wonder that we see all these problems.


The worst part is that some of the developers who originally wrote things are no longer here to help, so their knowledge and reasons, for doing things in certain ways, get lost.

I wish someone who groks filters well could write a proper document explaining most of (all?) the ins and outs of writing a proper filter. The old article written by rbb is nice, but a way too short to cover all the nuances.

--
__________________________________________________________________
Stas Bekman            JAm_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

Reply via email to