Re: Advancing IPv6 properly

mån 2007-02-12 klockan 21:34 +1300 skrev Amos Jeffries:

> Creating an IPAddress class to replace all the nasty macros
> currently used in the (incomplete) preperation of HEAD for the future
> ipv6 branch merge.

Yes, what I proposed when the branch was created..

> I am not certain at this point if the creation of such a class warrants
> it's own branch. One of the things I'd like guidance on is whether or
> not, and if so from where it would be best to branch.

Depends on what you think is easiest for what you think of doing.

If fixing up the existing branch in-place to make sense feels doable
then do so

If it's easier for you to start over from scratch and then bring over
the pieces which make sense from the existing branch then start a new
branch.

> My reasons:
> - The dev guides I have read on the site read that squid3 is meant to
> be a C++ program (objects and explicit types _NO_ macros) but has not
> yet been fully ported up as yet. This would form another small step in
> that upgrade path.

Yes.

> - The current ipv6 branch uses exclusively macros to enable a smooth
> upgrade when the ipv6 side of it is going. This is built into the nature
> of the branch and is partially moved up to HEAD already in preperation.
> Not a nice method of transition in an object-based app.

Yes.

> - Most of the ipv6 mods still need to be finished and tested anyway,
> so will not suffer greatly from the shrinkage thhis would cause.

Quite likely.

> Is it worth it? and would anyone with more knowledge of the future code
> than I have like to hazard a guess at an expected timespan for it?

I would think much of the groundwork of identifying IPv4 dependent parts
has been done already in the current ipv6 branch. So it shouldn't be
much more than implementing the class, and a big search/replace to make
use of it and to fix up a few remaining #ifdefs.

I would suspect doing it in the existing branch is easier as the code
sections needed to be touched is already identified there.. And
hopefully you may find that some of the transition can even be done
incrementally by redefining the macros to make use of the new class but
you know this code better than anyone else around here..

Regards
Henrik