Re: object oriented Squid ?

I agree....with a couple reservations. I've seen C++ and OO code that's
undoubtedly a true miracle of OO methodology. Unfortunately, it is NOT a
subscriber to the methodologies of 'legible' and 'modifiable'. Perhaps it's
faster to write code that is so cramped up and thick with the more abstruse
features of C++ that the average comptence-level C++ programmer still has no
clue. Maybe it runs faster.

In any case, these seem to be the sort of things that crop up:
<random-list>
<li> Peer selection. We want to be able to change the selection algorithm,
based on other factors. Either before, during or after the actual process.
(For example: Always using one parent, but switching to alternate 'single
parents' if the primary goes down, and never fetching from alternates when it
is up; or switching to another parent based on bandwidth/second drawn from the
primary)
<li> Hierarchy bypassing. Allowing the hierarchy to be bypassed based on other
factors, or enforcing the hierarchy despite other factors. (Users just don't
understand the message generated from NO_DIRECT_FAIL)
<li> Compressed or encrypted connections. Tapping into the low-level network
layer class, and plugging in other code or transport methods, including but
not limited to, compression, HTTP/1.1 multiplexing, feed-throttling.
<li> Custom authentication protocols. {big-bag-of-letters}AP stuff.
</random-list>

Now, with a clear class-ified structure, most of these could be bolted in in a
day or three each (some probably a little longer).
I'd vote yes to OOsquid, based on that clear class-ified structure...but I'm
not ALL that keen that I'd necessarily want to see two diverging development
strands.

One or the other should probably take our focus, and if we're going to OO-ise
anything, we should OO-ise 1.2, and not 1.1.
Comments?

D

Christian Khoury wrote:

> Henrik Nordstrom wrote:
> >
> > As A sparetime Squid developer that knows both C and C++ (and a bit of
> > Squid too), I must say that there are some other design issues that is
> > fare more interesing than rewriting it in C++..
> >
> > 1. A Threaded Squid. This would really speed up development since
> > threading makes it possible to have a linear flow of control. Keeping
> > track of 3 (or more) interrelated state machines is not at all easy. All
> > developers makes mistakes here sooner or later (including Duane W).
> >
> > 2. Comments in the code, describing what it does, and why...
> >
> > Then if the code is rewritten to according to this, maybe it should be
> > done in C++ or even Java?. I don't beleive writing it in C++ alone makes
> > Squid much easier to develop.
>
> If it makes it easier or harder to develop is not the issue here (i
> think). What matters more is the ability to extend Squid capabilities
> much easier by people who may not be working on Squid's code (like our
> peoject, for example). And, IMHO, i think that what also matters is
> really the design of a "good" OO version regardless of the language used
> (of course, it's better to use a world-wide OO language :-) ).
>
> Christian
>
> --
> Christian Khoury
> INRIA - Projet SOR - B.P. 105 - 78153 Le Chesnay Cedex - FRANCE
> Tel : +33 1 39 63 51 33 e-mail : Christian.Khoury@inria.fr

--
Note to evil sorcerers and mad scientists: don't ever, ever summon powerful
demons or rip holes in the fabric of space and time. It's never a good idea.
ICQ UIN: 3225440