Re: squid-3

Adrian Chadd wrote:

> Hrm. Right. Should we just start this from scratch?

Think so.

> 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.

Agreed.

> 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.

Ok.

I have reasonable frameworks for poll() and Linux SIGIO based network
code that could be put to use.

For a network I/O specification, I think the eventio specification is a
good startingpoint. Comments please.
<http://squid.sourceforge.net/eventio/>

The store API's needs to be redesigned somewhat to fit the outlined
goals.

My initial idea of project stages is
1. Basic design outline / guideline
2. Collect what may be useful API's and modules from current Squid
3. Get a reasonable I/O API's and core running. Note that there may be
synergies between disk I/O and network I/O in some models, while other
models have them fully separated.
4. A good request flow
5. Store API (accounting for '9' below)
6. Protocol API
7. Protocol implementations
8. Store implementations
9. Inter-cache protocol implementations

Several of the stages can be done in parallell.

Known async I/O models:
  select()
  poll()
  /dev/poll
  sigio
  aio (*)
  completetion ports (*)

Network<->disk strategies
  
  mmap
  sendfile

* = also applies to disk I/O.

Should probably start a web page somewhere where we collect relevant
stuff...

--
Henrik