Fwd: Re: Squid FS API, round 2

Adrian is apparently a bit trigger-happy to use that "Reply" button
instead of "Reply to all"... but he has now promised to aim better in
the future ;-)

Same goes for anyone else who carries design discussions in private mail
off the squid-dev list. This list exists because of a purpose, and it
solely is to discuss the design and implementation of Squid..

/Henrik

attached mail follows:

On Tue, Dec 19, 2000, Henrik Nordstrom wrote:
> Sounds sane, except that the the term StoreEntry is utterly
> inappropriate for this kind of struct.. and I will try to read your code
> changes if that is what you are asking for.

Yup, that covers it. I agree SToreEntry is the wrong term here, but
we can always change it afterwards.

> Notes:
>
> Multiple clients on a single FS object or internal object is quite
> trivial.

Yup.

> Mutliple clients on a single server object is the tricky business. But I
> doubt the value of this, especially so if partial object store get's
> implemented. Most times it seems to generate more problems than it
> solves (stalled connections, exessive memory use, and probably higher
> bandwidth usage due to stalled connections causing more reloads than
> needed)

Yup.

The, the neat thing here is that because the StoreEntry is now
the placeholder for a single connection, there isn't anything
stopping us from creating multiple StoreEntries and attaching
them all to the same reply object..

Again, it simplifies the logic somewhat in squid itself, the
tricky stuff is now pushed out to the reply objects (and
the file store ..)

Adrian

-- 
Adrian Chadd			"Here's five for the cake, and
<adrian@creative.net.au>	  five to buy a clue."
				    - Ryan, Whatever it Takes