On Tue, 2 Dec 1997, Dancer wrote:
> 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'....
True. There are a lot of examples of mis/ab-used C++. We should stay away
from any "hairy" OO stuff that usually leads to poor portability, bugs,
and misunderstanding. I believe that 95% of C++ benefits come from a very
straightforward use of basic (but still potent) C++ features.
> In any case, these seem to be the sort of things that crop up:
> ....
> 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 agree that the algorithms you have mentioned can be customized in a
plugin fashion with just a bit of C++. One might also add storage
architecture (standard vs. DB-like (one huge always open file for many
objects)), NOVM vs. VM choice, and caching policy.
I am sure other people can find other parts of Squid where there is no
single "standard" choice for an algorithm, and multiple options may be
needed. Without "plug-and-play" interfaces, we may and up with more than
just NOVM and VM versions to support.
> 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.
It does not make sense for me too. There should be one version of Squid, in
C++ or not.
> 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.
I doubt that 1.2 will wait another month or so. I think a (two months?)
"background" work for the _next_ major release is more reasonable.
Alex.
Received on Mon Dec 01 1997 - 20:47:11 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:37:49 MST