Hi Adrian,
Thanks for your answers. As I can understand you are talking about
the squid4 project. If you want an independent opinion, I believe that
it is not good idea to start striping the squid2.
You will get again the same mistakes done at squid3. For a such project
start from ground and then thieve code (and most important knowledge)
from squid2 and squid3 (and other projects too :-) ) to make what you
wand.
Squid has a lot of parts implemented like modules (acl's,
authentication, delay pools etc) which can modified to be loadable at
runtime.
A modular system needs different configuration system, different net-IO
etc. You want to support multi-threading but squid2 does not care about
it and you have to correct a lot of thinks to support it. What parts can
you keep from a striped squid2 version?
For such work, I think the best is to start from the base server (com_*
stack?), then add the configuration system then the http/ftp protocol
then acls as modules, etc...
If the base system is quite well designed then the others developers
will be able to convert parts they made for squid2 or squid3, or just
add new code as modules without having to known the overall squid
structure/code...
Regards,
Christos
Adrian Chadd wrote:
Now, I don't have icap on my list as a specific thing to support, but:
* I'd like to look at whats been done in the icap-2.6 patchset and
Squid-3 to plan the next evolution of the client, store and server
side codebases to neatly support ICAP as a module, rather than a
patch or a compile-time option with lots of #defines everywhere;
* But what I'd like to do is support all the modern architecture features
well - lots of CPUs - fast or slow; lots of RAM or as little RAM as
exists on an embedded board; support the modern disk IO patterns
much more efficiently than we do at the moment, etc.
This requires some pretty drastic internal changes - threading, at the
outside. Maybe multi-process if people can think of a portable way of
implementing it.
* I'd like to make the code as modular as possible so a lot of things are
simply loadable at runtime. Don't need the URL rewriter? Don't load the
module, no performance impact.
* But to do all of this we need to strip Squid all the way back to its core
bits, build fast, flexible code libraries and APIs which support all
the stuff we want to do - including, yes, icap. Its just too hard for me
to do all of the above with the Squid codebase dragging as much
history as it does.
