Re: commloops and modio development

Robert Collins wrote:

> If we can get informed by tcp when our out buffer is empty (or
> better yet hits a low water mark),

This is how it (sockets) works. The problem with the current code is how
and when Squid registers to receive these notifications.

> client_side checks the store
> to see if it can read more data, and if it can, write immediately.
> If it cannot, it just returns.
>
> If a client is getting back logged by the available data from the
> store, it simply tells the store that it doesn't want to be called
> when more data is available: it'll pull the data out.

This is what is being proposed for a long time.. I am only trying to cut
down the complexity in allowing this to get done. Multiple clients is
one, the ability to reattach is another. Both are by them selves quite
complex things which makes implementing this quite a bit harder.

> Web developers need to be rfc 2616 aware, and make use of the
> cache-control functionality for private revalidatable data,

First they must find ways to make it possible to revalidate the data at
all. If you look at the average DB driven web, you cannot revalidate
data. All they do is to provide a freshness ttl.

Hmm.. I think I am contradicting myself here.. please tell me if you can
find in what way ;-)

> No it doesn't require full downloading :-]
> iCAP defines a preview (I think it's 4kb), from which the virus
> scanner can request the rest of the object via a Continue response,
> or indicate that for that object it's seen enough, carry on.

Ok.

> So we need to buffer ~4K between the origin and the store. Then we either release the stream into the store, or loop it through the
> virus scanner without spooling it to store at all (from memory iCAP considered this issue carefully: if the iCAP server requests the
> whole object it must return the whole object to us. If no changes are made we MAY return our previously cached object - whether to
> spool the intermediary becomes a load/performance choice for us)

Good.. thought you only got a good/bad answer from the iCAP server, not
the whole thing. So it is only the iCAP server who has to spool objects.

> Again, that has been fairly well considered in the particular spec
> I am interested in - iCAP (see the IETF OPES working group). I am
> interested in more than iCAP, for example in-process data
> modification (like the gif animation breaking code), data stream
> protocol layer access rules on responses (ie break open CONNECT
> links when they are not SSL). Some of those are covered by iCAP too..

Cool.

/Henrik
Received on Sat Jan 13 2001 - 17:03:35 MST