Re: newhttp branch

On Fri, Apr 27, 2001, Robert Collins wrote:

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

Yup.

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

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

*nod*

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

Yup, kinda.

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

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.

Adrian

-- 
Adrian Chadd			"Two hundred and thirty-three thousand
<adrian@creative.net.au>	  times the speed of light.
			 	   Dear holy fucking shit."