Re: object oriented Squid ?

--MimeMultipartBoundary
Content-Type: TEXT/PLAIN; charset=US-ASCII

Apologies for cross-posting. I think this discussion could be more
appropriate for the "development" list:

---------- Forwarded message ----------
Date: Fri, 28 Nov 1997 09:09:11 -0600 (CST)
From: Alex Rousskov <rousskov@plains.NoDak.edu>
To: Christian Khoury <Christian.Khoury@inria.fr>
Cc: squid-users@nlanr.net
Subject: Re: object oriented Squid ?

On Fri, 28 Nov 1997, Christian Khoury wrote:

> Hi, does anyone know about an object oriented version of Squid? or even
> a project for developing one.....thanx

I would love to write Squid in C++. In fact, I was thinking about benefits
and drawbacks of doing that for quite a while. IMHO,

0) It is definitely feasible:

        Squid runs on Unix platforms and is compiled using gcc. Thus,
there should be no major problems switching to g++. Low level I/O stuff
can still use C libraries wrapped nicely into appropriate classes. C++ has
no additional overhead compared to C if you know what you are doing. Core
C++ stuff is definitely at _least_ as portable as C code.

1) It is very useful:

        a) Object oriented version of Squid could significantly speedup
further development and enhancement. IMHO, it would be much easier to try
new things in a properly designed OO Squid than it is in the current
version. Adding a new scheduling algorithm or caching policy would be much
easier. As a side effect, we could merge NOVM and VM branches back
together because their actual essential difference can be localized in one
or two interchangeable algorithms.

        b) Many things that cannot be easely fixed in the current Squid
could be changed with little effort if an OO version is in place. For
example, 50% smaller store_entry structures using MD5 or similar encoding
of URLs, etc. Now, it can be done in the current Squid as well, but it
would take more time and efforts; and when the result is questionable
(memory vs. CPU tradeoff), we will probably never try it. Having a
carefully designed OO version, we could supply both versions with a little
extra effort.

        c) Adding various kinds of performance measurements and tuning is
really easier when all actions are localized in classes, a client request
is not represented by 3 isolated structures and does not change its
"state" in 5 places that share no common data structures, etc.

2) It can kill Squid:

        I wish everybody in Squid community were C++ fans. Object
orientedness clearly enhances collaboration _provided_ that all
participants know what they are doing. However, it is probably not the
case. Many nice folks who contribute to Squid development do not know C++.
My major concern is that there will be almost no contributers left if we
switch to C++. I wish I were wrong.

        One could argue that with a C++ Squid, one could still write a
C-style "local" code. That is probably true, but all significant changes
would still require some understanding of OO concepts.

        On the other hand, IMHO, OO is the programming technology of the
future so why not to "push the envelope"? :)

Any comments?

Alex.

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:44 MDT