Re: commloops and modio development

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Adrian Chadd" <adrian@creative.net.au>
Cc: <squid-dev@squid-cache.org>
Sent: Saturday, January 13, 2001 8:45 AM
Subject: Re: commloops and modio development

> > Optimally I'd like the solution to not require large amounts of
> > incoming buffering from the network server side. This may be a
> > tall order, but I would like to kill the use of the stmem routines
> > to buffer network IO (and use them to buffer "auto generated"
> > data by squid..)
>
> I'll second this I think, and kill the feature that there can be
> multiple clients listening to one server connection. Having the
> possibility of multiple clients makes things quite complicated.

It may make it complex, but on low bandwidth sites, it's a must (in my book). Plus when auto downloading programs (like mozilla
setup) think there's been an error and restart, ending up with two parallel downloads. No leave this in please. Really.

>
> I'd also kill the ability to reattach to a "not-yet-aborted" request,
> based on the assumption that we can implement storate of partial
> objects.

I don't agree with this. Henrik I think you raised the point that early abort should still exist to control when to stop the object
download and cache the partial, and when to finish it anyway. However it's not a big loss compared to the first item, so I'm not
going to stress as much :-]. The point about this is that dynamic objects won't be satisfiable by combining ranges, but are
satisfiable by fully cached objects.

> So exacly how simple can "single client per server connection" get:
> * no need for deferred reading
> * no need for buffering
>
> Why no need for deferred reads:
>
> It is handled automatically by the dataflow. When the client wants data
> you try to read. If there is no data then register for notification of
> available data.
>

Uhmm, I am actively (read in my copious spare time) preparing to put hooks into squid to allow modification of data coming into
squid, before it hits the store & clients, and also for data leaving squid to the clients. This is for eventual iCAP integration.
(so virus scanners can sit beside squid, not above it as parents).

> Why no need for buffering:
>
> Data is immediately sent to the listening client.
>
> Yes, there will be limited need for buffering while parsing the protocol
> (HTTP headers or TE).

& sending out to data modification handlers.

Does this make things too complex? Or do we attached several streams in a row (client to clientside datamod to store to serverside
datamod to origin)?
Received on Fri Jan 12 2001 - 22:11:23 MST