Re: refcounted buffers / squid-3

On Tue, Jul 10, 2001, Henrik Nordstrom wrote:
> Adrian Chadd wrote:
>
> > (ObNote: the wall I hit is that storeRead/storeWrite buffers aren't
> > refcounted in any fashion, so there wasn't an easy way for the IO
> > layers to know whether the buffer was still valid.
>
> Have the same problem in eventio... a big pain.
>
> Started to transition Squid from "caller owns buffer" to "refcounted
> buffers", but it requires a quite extensive rewrite of many things
> unless one wants to use huge amounts of glue to stick things together
> which somewhat defeats the purpose...

Yup.

> Looks like it is about time for a Squid version 3 design. My starting
> point are
>
> * refcounted buffers, created at the data source.
>
> * "abstract" asyncronous I/O layers/modules, taking care of all details
> of how to perform I/O, I/O event notification and so on.
>
> * Possibly different I/O layers for differnt parts (networking, disk
> I/O, storage I/O, ...)
>
> * HTTP headers only parsed once
>
> * Modular design
>
> * Cleaner store interface
>
> * Support for partial objects
>
> * Support for per-URL Vary/ETag object indexes
>
> * Support for multiple store indexes, even down to having each cache_dir
> manage it's own index.
>
> * All store operations (including index queries) asyncronous.

Hrm. Right. Should we just start this from scratch?
I think it would be a good idea. Along the way we can nab things
such as the debug code, but I'd rather not be hindered by all the
old code thats there.

Learn from it, but don't let it drag you back.

I'm definitely more than willing to work on the disk and network IO
side of things, if enough people are willing to work on the rest.
I would propose that we should write a single-threaded proxy server
to start with, to test out some of the above ideas.

adrian

-- 
Adrian Chadd			Yeah, for me its (XML) like the movie Titanic.
<adrian@creative.net.au>	  Everybody loves it.
				    I want to be different, so I hate it.
					--Duane Wessels