RE: handling ranges in squid-modio

> -----Original Message-----
> From: Adrian Chadd [mailto:adrian@creative.net.au]
> Sent: Thursday, February 22, 2001 8:47 AM
> To: Robert Collins
> Cc: squid-dev@squid-cache.org
> Subject: Re: handling ranges in squid-modio
>
>
> On Thu, Feb 22, 2001, Robert Collins wrote:
>
>
> nono.. I mean store -> client is linear. The client can send to the
> store a range request, and it'll get back a linear response. Whether
> the linear response is a single or multipart response isn't relevant
> here. The linearness is.

Cool. And that will be _raw_ data, not http encoded parts?
 
> > > When I've tracked down any remaining ones I can continue reworking
> > > the server/client data flows and then move on to sepearating the
> > > header part from the data(body) part.
> >
> > Yes. Gor for it, delete away :]. I'll try to get a minimal
> intermediary
> > in place in the next couple of weeks.
>
> With what ?

The framework Henrik and I discussed last week - that implements the T
junction between server side, client side and store code in one place.

A minimal implementation to me is: all server side logic out of
client_side.c, all client_side logic out of (ftp/wais/http/gopher).c &
all storeAppend & storeClientCopy calls removed and moved to the
intermediary & the intermediary able to handle basic requests cleanly,
with the range interface present, but awaiting the store to catch up.
 
> > > We're assuming here that each object will have a "header"
> part and a
> > > "body" part, right ? This would be a nice time to tell me.
> > >
> > > :-)
> > >
> >
> > Every object that hits the store will have metadata and body.
> > Metadata will include parsed protocol headers, time recieved by the
> > cache....
>
> Right.
>
> > The Body is a set of potentially non contigous ranges
> belonging to the
> > same instance of the object. (with offset 0 the beginning
> of the body,
> > NOT the beginning of the response).
>
> Right.
>
> > This implies a function to write|update the metadata, and another
> > funciton to retrieve it.
>
> Right.
>
> > The only question I have is "Varies" - does the store know about
> > variations, or does the (currently hypothetical)
> intermediary make sure
> > the store gets given different keys?
>
> The store is going to know what to return to the client. The store
> implements the vary support. Henrik and I outlined that different
> features of HTTP/1.1 are going to be supported with varying profiles
> (speed, savings, etc) and so its better left up to the store to choose
> something cute.

But the store is not HTTP aware right? so it'll be doing this on generic
metadata? (i.e. the concept of varies and ETags can be generalised, and
its the general implementation the store does).

> So, single metadata section, multiple "bodies". Right. Uhm, I'll
> keep that in mind and come back to you when I get to that stage. :)
 
Cool.
 

Rob
Received on Wed Feb 21 2001 - 15:27:57 MST