apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: cvs commit: apr-util/include apr_buckets.h
Date Fri, 31 May 2002 21:19:16 GMT
> From: Cliff Woolley [mailto:jwoolley@virginia.edu]
> On Fri, 31 May 2002, Ryan Bloom wrote:
> > I considered that, but I am actually thinking of the future, where
> > 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
> > and should be marked as such.  However, the headers are likely to be
> > HEAP buckets, which means that the metadata flag really has to be in
> > bucket itself, not the bucket_type.
> That's a different definition of metadata than the one I was using, in
> that by that method the length would be non-zero.  I always envisioned
> header data as being in a new type of bucket, one which contains an
> apr_table_t as metadata and is zero-length.  The length should always
> data, never metadata.

Length does always mean data, but length has nothing to do with this
discussion.  As I said the other day, there are two types of metadata,
filter metadata, and request metadata.  This flag currently refers only
to filter metadata (which means that the bucket itself is the metadata),
but in the future it must also be useful to state that the data
contained in the bucket is metadata, this would be request metadata.

Even if the headers start as a special bucket, at some point in the
filtering, they could easily be converted to a HEAP bucket.  In fact,
most filters will convert headers to HEAP data so that they are easier
to read and modify.

The length field should ALWAYS represent the amount of data stored in
the bucket that will be sent to the client.


View raw message