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?

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.

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

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.

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

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

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