modio v2 progress

From: Adrian Chadd <adrian@dont-contact.us>
Date: Thu, 21 Dec 2000 22:49:25 +0800

Besides the occasional bugfix here and there, the modio branch
is running ok and passing some polygraph and browsing tests.

The modio squid will now proxy only, and I wouldn't even try it
in a cache hierarchy.

Now I'm going to need a little help. The internal reply object
is very very basic and is suited only for small objects
(I could spend the 2 minutes it'd take for me to stick
a stmemFree() in the right place, but I haven't .)
and so the next "reply object" is going to be the network reply
object.

<background>

StoreEntry's are now dynamic. Every storeentry will have a
memobject attached to it, because it only exists for the
lifetime of a connection. I envisage three parts to this
new and improved StoreEntry:

* a client, who wants some data
* a server, who feeds some data
* a backing store, or "reply" object as Henrik I believe coined

I've written the 'internal' reply object which is designed for
things such as error pages. It stuffs data from storeAppend() into
an stmem list, and copies data from it to a client through
storeClientCopy().

Each StoreEntry will now support a single store client. Multiple
store clients can be handled by the appropriately intelligent
reply object. (I don't like this name, I like 'backing object'
better.)

I've hacked up the http code to use the internal reply object
for the time being, which turned squid into a straight proxy.
This is nice and simple whilst the store code is tidied up,
and other code is rewritten.

</background>

I'd like some feedback here. Personally I'd like to keep the
network object as simple as possible - don't copy memory between
client/server where it isn't needed, change the semantics around
a little to only get data from a server if the client needs it
(to facilitate event-driven IO systems... I've done this in a
roundabout way in commloops but I'd like some feedback on other
ideas people might have), and continue tidying up some of the
existing store code.

Since we don't perform a lookup in a central database aymore,
the storeSetPublicKey() and storeSetPrivateKey() along with
some of the magic entained needs to be untangled ..

Help ? :-)

Adrian

-- 
Adrian Chadd			"Here's five for the cake, and
<adrian@creative.net.au>	  five to buy a clue."
				    - Ryan, Whatever it Takes
Received on Thu Dec 21 2000 - 07:49:35 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:06 MST