On Fri, May 31, 2002 at 02:08:02PM -0700, Ryan Bloom wrote: > > From: Cliff Woolley [mailto:[EMAIL PROTECTED] > > On 31 May 2002 [EMAIL PROTECTED] wrote: >... > > > Log: > > > Make buckets advertise if they are filled with metadata or not. > > > Long-term, we most likely want to extend this so that buckets can have > > > more states than just "data" or "metadata". For now, this is enough. > > > > I'd much rather see this flag be in the apr_bucket_type_t than in the > > apr_bucket. As it is now, not only is it one more thing to have to set at > > runtime, we'll now have to worry about making sure it's set right if we > > want to morph.
++1 In fact, I'll go so far as to -1 the current per-bucket [rather than per-type] implementation. > I considered that, but I am actually thinking of the future, where there > are different types of data. For example, when we want to send the > headers down the filter stack as a part of the brigade, that is metadata > and should be marked as such. However, the headers are likely to be in > HEAP buckets, which means that the metadata flag really has to be in the > bucket itself, not the bucket_type. Absolutely not. It is header data and should be a header data bucket. You don't just drop it into a standard "content" bucket. If you want to copy the HEAP bucket "type" definition (e.g. copy over the vtable entries) as a way to implement your header bucket, then fine. But a bucket type should be metadata, or it should be data. The metadata flag is about the bucket *TYPE*, not about the contents. I will also point out that a "header" bucket would contain a hash table would return 0 bytes from its read() call. You don't want filters processing that stuff as if it was regular content. When HTTP_OUT receives the bucket, it will do the appropriate serialization onto the wire. Cheers, -g -- Greg Stein, http://www.lyra.org/
