Re: refcounted buffers / squid-3

From: Adrian Chadd <>
Date: Wed, 11 Jul 2001 14:30:34 +0800

On Tue, Jul 10, 2001, Alex Rousskov wrote:
> Being only a human, my opinions should be taken with a grain of salt.


[snip good points as well as good points from joe]

> Now, the stuff above is not really important. :) The fact that several
> current developers want a rewrite _and_ will have fun/paychecks doing
> it is what going to drive the short-term decision making, I guess.

Oh, I'm all up for the fun aspect. But I won't complain if the latter
happens. :-)

> P.S. Between the two of us, I do not really care about features and
> all those parsing optimization ideas. I am all for/against the
> rewrite if Squid3 is written in C++/C! ;-)

*laugh* You've been pushing a reimplementation in C++ for a while now. :-)
At least in my experience, C++ would be suited from a language point
of view to implement squid with. Every time I've rewritten or attempted
to rewrite/add something I'm always thinking "should I add a 'done'
handler to this $OBJECT_PARENT_TYPE so we can just call $obj->done
and have it take care of whatever cleaning the $child requires?",
but then I realise that it might just make me switch into C++ mode. :-)

Joe - don't get me wrong. If we were to rewrite squid (in C, with
well-defined APIs, and a script to make sure people aren't abusing struct
members .. :-) there will be chunks of the code we could:

* rip quickly and easily, with a minimum amount of change
  (eg the DNS code, the debugging code, the hash/tree/etc code)
* rip reasonably quickly, with a moderate amount of improvement
  (eg the network code)
* rip reasonably quickly, with the changes that are in the pipeline
  but can't be finished without squid being improved (eg my disk/FS code,
  perhaps roberts te/newhttp code)

Then there will be bits we rewrite, but *learning* from the existing


Adrian Chadd			Yeah, for me its (XML) like the movie Titanic.
<>	  Everybody loves it.
				    I want to be different, so I hate it.
					--Duane Wessels
Received on Wed Jul 11 2001 - 00:30:42 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:06 MST