Re: squid3 comments

On Tue, Feb 27, 2007, Tsantilas Christos wrote:

> Ok Adrian, I am watching the mailing list and I know what you want to
> do. I believe too that some parts of squid needs redesign, if the
> project wants to survive. Squid is an old and huge project. And you
> must continue your work because you want a fast http proxy, with cleaner
> code and better api's .

Yup. Well, I want more than a fast http proxy. I want a faster, simpler,
better structured proxy thats flexible enough to be a testbed for all
kinds of new stuff.

> In the other hand I need a proxy with an icap client because I spent
> time (and continue spending) to an icap related project. Squid3 has a
> good icap client. The first problem someones can see in squid3 is that
> there are some parts derived from c-code, which are not (fully)
> converted to real c++ code. The second is a feeling that some parts of
> code are half-completed. I am thinking that maybe it is good practice
> for someone to start fixing this things first....
>
> An alternate for me is to try fix the bugs and rewrite some of the
> icap-related parts of the squid26-icap branch. I don't know ....

I'm going to be perfectly honest, and this is just my opinion.
I think Squid-3 is ultimately a dead end. I think the people involved
got a bit overenthusiastic with applying a whole lot of paradigms which,
to be honest, just haven't delivered. So the project stalled and
I don't think its going to be going anywhere in a hurry. I tried pushing
it along myself for a few months but then I realised Squid-3 was just
as complicated as Squid-2, with all of the horribleness of Squid-3 inside
and compounded by almost-implemented data types and little understanding
of the changes made (for example, the RefCounted stuff is a great idea
but its not an immediate dropin replacement for cbdata. A lot of core
routines were converted over with some pretty disasterous results.)

C++ is a good idea and I think in the long run its the kind of direction
the codebase has to take - but we shouldn't have converted the Squid
codebase to C++ at the stage it was at.

We shouldn't have tried to convert stuff over to C++ without first giving
the code a good half dozen passthroughs, simplifying what was there
and giving everything a good tidyup. Unfortunately that wasn't done -
lots of refactoring was done but nothing was ever really "fixed".

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.

Now, these are all my opinions and are definitely not to be taken
as the opinions of others or the Squid project in general.

(and I should be coding.)

Adrian
Received on Tue Feb 27 2007 - 07:11:34 MST