Re: squid3 comments

From: Jeremy Hall <jehall@dont-contact.us>
Date: Tue, 27 Feb 2007 08:36:54 -0500

>>> Tsantilas Christos <chtsanti@users.sourceforge.net> 02/27/07 6:27
AM >>>
Hi Adrian,

Adrian Chadd wrote:
   
agree .....
> Yes, I'd like to do all of what you've suggested above but I'm going
to do it by
> junking most of the client-side request/reply handling routines and
replacing them
> with stuff written from the ground up to use a sane API. Buffers
won't be copied;
> stuff will be parsed once and parsed quickly; the whole of the URL
rewrite/XFF/
> Acceleration/ACL lookups/etc will be implemented as a state engine
with events
> rather than callback-driven like it is today. Its also doable in a
-lot- less code
> than is traversed today.
>
> I believe the only way we're going to get long-term benefits out of
any improvement
> work is to pick some medium term goals (mostly structured around
knowing what
> we'd like the code to look and picking incremental API and code
decisions which
> take us down that path) and working on them piece by piece.
>
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 .

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

Let me second this. When you start asking questions about squid3 and
its stability, you get anything from "it's stable" to "not for prime
time" and when you ask questions about using it in a production
environment, most shy away from that.

but I need ICAP support and proposals like this, although valid, scare
me a little. (rewriting the client side code from scratch, not putting
icap in 2.6)

I don't have the time to go digging on 2.6 to make icap work better, so
if you have some spare cycles it would be greatly appreciated.

_J

Regards,
      Christos
Received on Tue Feb 27 2007 - 06:37:52 MST

This archive was generated by hypermail pre-2.1.9 : Thu Mar 01 2007 - 12:00:02 MST