Re: squid-3

Joe Cooper wrote:

> I recall a recent article (which I can't seem to find, unfortunately)
> that made a very strong case for /never/ throwing away a large working
> code base, particularly one like Squid that has to be compatible with so
> many different clients and servers.

And we aren't, from mostly the same reasons outlined in your message.
But we are starting over from scratch to build a new basic framework,
then adding back what can be reused of the old codebase where possible,
rewriting what can not.

The reason to this is that very basic design changes is required to
allow us to continue, and doing these changes inline is not practically
possible.

If you understood me in that we will not look at the old code or use
what can be used then perhaps I expressed myself poorly.

> 1. The code is so old and crufty!

I would not say it that way. We are facing design changes where the old
code is very much in the way, forcing these changes to be done in a poor
and crufty way from start if it has to live with the old code.

> Perhaps, but the code works.

The code works yes, but it is at the point where it is not practical to
continue extending the code. Many of the problems we are facing tuday is
from basic design assumptions made at day 1, not the code as such. The
code is a result of these design assumptions, and as such is valid.

> Do you believe all new code will be any
> less crufty by the time it supports every user as well as the current
> code base? Contrary to common 'bit rot' theories, the code that was
> written 5 years ago is no less and no more solid than it was 5 years
> ago. Were the people who wrote Squid back then lesser programmers than
> the folks working on Squid today?

The remaining 5 year old code is most likely more stable today than it
was 5 years ago, both from having bugs fixed and from gradual design
changes improving reliability. However, in the process new programming
techniques have been learnt and OS designs have moved forward, both in
ways not fitting all that well together with basic principles in the
original design of Squid.

> More importantly, would fixing the cruft in the current code base,
> one piece at a time, be faster than writing all new cruft and then
> fixing it?

See response at the top.

> Can the current Squid developers build a new Squid that not only fixes
> the current problems in areas they are experts in--but does not
> introduce all new problems in areas that are not familiar territory?

Probably not, but we have a quite wide knowledge base in the areas
related to Squid..

> You'll be working in areas that nobody has even really looked at in
> years...does the current team have the expertise in those old musty
> corners (many of which are probably coded pretty well right now) to
> recreate them flawlessly? Admittedly, a lot of those dusty corners were
> badly written from the start and can only be improved by being
> trashed--but without expertise in each of those areas, of which Squid
> has a lot of diverse areas, Squid will gain as many flaws as it loses.

Most of these corners is not as dusty as it may seem, and many of them
will quite likely be reused as they are with only some small changes.
Others will have to be rewritten completely.

> Henrik could rip out the poll code, and replace it with something much
> better...

Problem is that I cannot do that without also rewriting most of the
other code using it, which in turn requies rewrites of most code using
that code...

If I then find that the path selected was not the best one then it is
already too late to do anything about it.

> As an aside, I've recently received permission from Alex to use
> Polygraph for a new set of public benchmarks (the new Polygraph license
> prohibits this generally) of the current Squid. I plan to use Andres
> profiling tools to really dig in and locate the time sinks in Squid more
> precisely and graph it all out nicely.

That is wonderful news. Thanks Alex / The Measurement Factory.

--
Henrik