RE: newhttp branch

> -----Original Message-----
> From: Adrian Chadd [mailto:adrian@creative.net.au]
> Sent: Friday, April 27, 2001 4:14 PM
> To: squid-dev@squid-cache.org
> Subject: Re: newhttp branch
>
>
> On Fri, Apr 27, 2001, Robert Collins wrote:
> > Does this tie into building the protocol intermediary thats
> been bounced
> > around?
>
> Well, kinda. Did you seemy servlet/clientlet idea from earlier on
> this year/late last year?

Sort of :]
 
> The idea is that the central objects will be 'clientlets' which
> define one sid of a connection. So, a http client creates a
> clientlet for the http request, and passes it to (say)
> storeLookup(). storeLookup() will then take the request info
> and attempt to find a matching protocol/traslator for the "other"
> side of that connection.
>
> That connection (another clientlet) might be a store backed object
> from cache, or a HTTP server connection, or an FTP server connection.

What I've nutted out with henrik takes this a little further:

you are describing a chain of objects , with storelookup somewhere in
the chain.

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).

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.

In this model the data filter chains are a 1-1 mapping with your
clientlets. (ie the code is done and working). I have these on both the
client and server side.

What's missing is the rearrangement to a clear three pronged
arrangement. Other than that it's done :]. (Do you recall my questions
about modio with respect to this ?)
 
> However, each clientlet protocol type will have defined a bunch
> of methods to be able to translate to/from other protocols.
> So, if we write an FTP client side we'll just need a couple
> of routines (one in the client clientlet, one in the server clientle)
> to translate from PROTO_FTP to PROTO_FTP. HTTP client to FTP server
> will need something that'll trslate PROTO_HTTP to PROTO_FTP.
>
> This way we can then add new client/server types without all the
> srangeness and code duplication that'd happen. well, in theory. :-)

If the middle of the chain takes a canonicalised request, even less code
is needed (only a new client protocol or new server protocol).
 
> Purists might argue that this kind of OO orientated design might
> suit C++ better. My argument is that I'm simply testing out an
> idea and if this idea looks like its going to work I'll revisit
> the language question.

Ditto :]
 
> I've been waching your filter/modular work and it looks rather nifty.
> If my work suceeds we should be able o implement much more of
> HTTP/1.1 and allow people to easily insert content filters and
> the like in the path (the "cache" part will be a content filter,
> strangely enough. :-)

Um yeah - thats exactly why the filters code is paused. A) I added to
much to the branch (filters + modules) and B) I didn't want to change
the request flow to the broker model until modio was available in a less
fluid form.

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

I understand :]

Rob
Received on Fri Apr 27 2001 - 00:33:29 MDT