Re: Transfer-encoding.

I'll look into it. I seem to have volunteered to work on rproxy - I
expressed interest in it :-/.

interface==API?

well for http/1.1 chunk support is compulsory, so I suggest we work with
chunks internally. Then the API must be able to return a list of stored
entity ranges, AND a list of available chunks.

storing other te formats could be done by having a field on create and write
requests to indicate the object format. I think that storing other te
formats will be a loss in the long run. How often will you want to send a
gzip te to a client, vs gzip or rsync? storing the gcd seems sensible and
(to me) that's chunks. (then we can say squid keeps chunks...)

----- Original Message -----
From: "Adrian Chadd" <adrian@creative.net.au>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Tuesday, November 14, 2000 10:39 PM
Subject: Re: Transfer-encoding.

> On Mon, Nov 13, 2000, Robert Collins wrote:
> > Just a note: the te branch is slightly broken at the moment, so I took
the
> > time to see the code when I was fixing my checked out branch...
> >
> > As a design decision, should squid be storing the te version of
entities, or
> > the 'identity' version? is the storeio interface up to storing te
entities?
> >
> > The te branch seems to do all the decoding in client_side, which AFAIK
means
> > that the cached entity will be the te version.
> >
> > I think storing entities as a series of chunk-encoded sections might be
very
> > useful - ie for storing partial responses.
> >
> > Comments?
>
> Yes, I think being able to store chunks of objects would be a big plus
> here. I think I should consider this in the storage manager rewrite.
> However, I don't know how long it'll be before I have a storage interface
> ready to deal with this.
>
> Hrm, what kind of interface would you need for storing TE entities?
>
> --
> Adrian Chadd "God: Damn! I left pot everywhere!
> <adrian@creative.net.au> Now I'll have to create Republicans!"
> - Bill Hicks
>
Received on Tue Nov 14 2000 - 06:36:56 MST