Re: newhttp branch

----- Original Message -----
From: "Adrian Chadd" <adrian@creative.net.au>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Friday, April 27, 2001 6:02 PM
Subject: Re: newhttp branch

> On Fri, Apr 27, 2001, Robert Collins wrote:
>
> > The intermediary architecture (it's all in the dev archives) is very
> > similar, ..but..
> >
> > Rather than storelookup in the chain, there is a protocol
intermediary
> > (I think broker is a better name btw).
>
> Yeah, a broker is a much better name for it.
>
> > ie client side protocol = icp/http/ftp
> > server side protocol = http/gopher/wais/icp/rtsp...
> > the broker matches client side to server side, and copies data
off to
> > the store or from the store as appropriate. The broker takes a
> > generalised|canonicalised request/response which is _not_ http
specific.
>
> I was thinking of just taking a "copy" as the data comes off, but
> there might be different types of storage depending upon the protocol
> type (eg streaming media storage != http object storage) and having
> the storage manager itself present a set of clientlets makes this
> integration seamless.

The broker will make that more effective, not less.... as its the
junction point between cache,server side and client side it can choose
between mutliple different object storage locations as appropriate.
copying off is probably a bad description :]

> > I am happy to put in a solid weekend and finish moving
rbcollins.filters
> > to content.processing if you want to pickup what I've done (as IMO
it is
> > really clientlets) and take it from there. At the moment I've really
> > just been pushing the module code to finish that off and get it into
> > head.
> >
> > > Oh, yeah.. I'm preparing myself for some coding because I'm
> > > going on holiday in a couple of weeks. Thats the only time
> > > I actually get to do some real work. :-P
> >
>
> Ok. The main reasoning for me to play with the http code is
> to rip out awhole hepap of stuff that shouldn't be there
> (eg the range request handling) and throw the headers parsed
> between client/server to save on parsing.

I'm 50% thru Range requests - just waiting on modio support for range in
objects. Header parsing is about 80% done - waiting on the (storemanager
to handle headers outside of the data stream) || (the broker interface).

So I guess I'm really saying that between us, if you can add the
appropriate logic to modio, or to content_processing if I move
rbcollins.filters to content processing (where it should be) and then
merge modio down there as well; the only significant code mangling
needed should be in the store* interfaces. - do you want to collaborate
on this bit?

Rob

> Adrian
>
> --
> Adrian Chadd "Two hundred and thirty-three thousand
> <adrian@creative.net.au> times the speed of light.
> Dear holy fucking shit."
>
Received on Fri Apr 27 2001 - 02:38:27 MDT