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