Re: Squid-2.6 merge fest

Adrian Chadd wrote:
>
> On Thu, Apr 04, 2002, Henrik Nordstrom wrote:
>
> > > I'm enforcing the latter, and I'm hoping the former is done (or you won't
> > > parse the headers, right? :)
> >
> > Yes.
> >
> > What?
>
> What were you after exactly?

From where the comment on header parsing came into the picture? But I
got it now (I first misread former/latter, which made me somewhat
confused..)

> Well, now they have to keep the data that they want to reuse.

Which is fine. The old two-offset way was only confusing and very
dangerous as it easily lead to coding errors, even if slightly handy
once understood..

> > One range per storeLookup(), or a list of ranges?
>
> I don't know. Pick one. :)

Multiple. There are way to many races otherwise.

Then the question arises on how do you signal the returned ranges to the
caller? As a linear stream with the ranges concatenated, or structured
somehow?

And how to deal with partial objects where only part of the requested
range or ranges can be satisfied?

To be honest I question the need of having ranges passed at all to
storeLookup. If ranges are to be passed to storeLookup then it should
only be as a condition (these ranges MUST be present). Simply have
storeLookup return a indication that this object is only partially
available, and device a client API on how to retreive selected ranges
from the returned object handle and possibly an API to query which
ranges can be satisfied.. The whole business on how to properly deal
with retreival and storage of partial objects is a complicated mess.
Before doing anything on the store on this a good view must be taken on
the full picture, not just storage and storage retreival of parts of
objects.

Vary processing belongs at the store layer.

Regards
Henrik
Received on Fri Apr 05 2002 - 02:20:19 MST