Re: [dev-serveez] IPv6 prep

[Thien-Thi Nguyen]

() Raimund 'Raimi' Jacob <address@hidden>
() Wed, 25 May 2011 06:58:34 +0200

   Hm. that address union seems to be the logical thing to do (and also allows
   for that IPX-to-IPv6 protocol converter I always dreamed of :).

Cool.

   I'd just note that there is no real need to stress the opaqueness of struct
   svz_address. serveez is a networking framework and this struct is a small
   abstraction over address families. I'd have no problem exposing that to 
client
   code. This also somewhat forces you to keep that struct small and simple -
   that's what it should be :)

Well, here's the problem.  As latest q-addr HEAD (e6e688e3f) shows,
if ‘struct svz_address’ is exposed, we now have a preprocessor conditional
in address.h and the possibility of ABI incompatability.  Specifically:

- Is ‘_POSIX_IPV6’ correct?
- If so, will it be correct, forever?
- If not, will it be incorrect, forever?
- What is the woe32 equivalent?
- What is ‘sizeof (svz_address_t)’?
- etc.

This would only get worse with the addition of support for other families
(e.g., IPX) to the union, whether conditionally or unconditionally.

(Perhaps i'm not expressing myself clearly here.  To justify opacity, i
imagine myself as J.R.Programmer playing with libserveez from Serveez 0.2.0,
0.2.1, 1.42.foo, etc, and cursing ttn for futzing w/ the ‘struct svz_address’
Yet Another Time, breaking my i-just-want-good-old-IPv4 code.  I'm paying for
abstraction (s/in_addr_t/svz_address_t */g), but got instead distraction!)

So, i think i will try to formulate these fears (-) into a good comment (+)
and revert the code to opaque ‘svz_address_t’.  It's true that we want to keep
things simple, but i think in this case the simplicity of API/ABI stability
outweighs the simplicity of transparency.