httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <>
Subject RE: cvs commit: httpd-2.0/modules/test mod_bucketeer.c
Date Thu, 30 May 2002 23:14:34 GMT
> From: Cliff Woolley []
> On Thu, 30 May 2002, Ryan Bloom wrote:
> > I didn't think it _had_ to auto-morph.  My understanding is that the
> > default buckets do, because we assume the performance will be better
> > they do.  That makes sense, because a file_bucket is likely to be
> > multiple times, so it makes sense to morph the bucket on the first
> > so that we don't have to go to the disk twice.
> If it didn't, how could you possibly pass back a buffer containing the
> data?  In other words, I guess there's no hard and fast rule that it
> to actually morph, but since it's doing all the work of copying that
> into an in-memory buffer anyway, it doesn't make much sense *not* to
> to a bucket type that handles in-memory buffers.  Sure it could
allocate a
> new buffer and redo the copy every single time it was read from, but
> would it want to?  <shrug>

Agreed, but I can think of one case.  (a bit of hand-waving, but a
possibility, nonetheless) :-)  If I write two filters that work in
tandem to solve a problem, I may want to use a special bucket type to
facilitate them working together.  For example, if I have a bucket type
that encodes graphics in lists of RGB values, then the read function
MUST return a binary buffer of data, but later filters will most likely
find it MUCH easier to deal with the RGB values directly.  So, in this
case, I could have a handler that served graphics files by filling out
this special bucket, and a filter later on that added a watermark.  Any
filter in between the two will still have to be able to read from the
bucket, but the watermark filter will be able to operate much better on
the RGB values.

That is the only type of case that would make sense to keep the data in
a different structure.   :-)


View raw message