httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: [PATCH] Filter registration.
Date Fri, 28 Jul 2000 21:56:00 GMT
>>That is the data inside the bucket.  The bucket structure itself is
>>rarely usable across invocations because of the way filters work -- they
>>end up either transforming the data (in which case the bucket goes away)
>>or storing the data in a way that is efficient for later processing
>>(in which case the bucket will most likely go away).
>
>But then the data has changed too, so you still have the situation
>that the lifetime of the bucket is the same as its contents. The same
>is true for the bottom filter if it concatenates the buckets when it
>saves the contents: the old data and buckets are destroyed and
>replaced by new ones. I think that if you keep the bucket and content
>lifetimes the same then it will simplify the rules you have to follow
>to ensure that buckets are used correctly.

The data doesn't change -- it gets copied to other places, or new
references to it are created.  E.g., when we truncate a bucket, all we
are doing is reducing the length size within the bucket structure.
This is the part that comes from IO-Lite -- we have some cache of data
objects and a bunch of buckets that reference parts (or wholes) of those
data objects, and the filters process a stream of buckets, some of which
reference cached objects while others reference the stack or the heap
or whatever else feels right at the moment.

I'm not sure how far we can go with that, since some data sources can
only be "read" from a single point.

Kevin, this is object-oriented design -- OOP is for wimps.  ;-)
Seriously, the problem with OOP terminology is that it is language-specific
and subject to the buggy whims of C++ vs Eiffel vs Ada95 vs Python vs ...

....Roy

Mime
View raw message