> From: Cliff Woolley [mailto:[EMAIL PROTECTED]] > > 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 if > > they do. That makes sense, because a file_bucket is likely to be read > > multiple times, so it makes sense to morph the bucket on the first read, > > 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 *has* > to actually morph, but since it's doing all the work of copying that data > into an in-memory buffer anyway, it doesn't make much sense *not* to morph > 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 why > 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. :-) Ryan
