Le lundi 12 mars 2007 18:50, Julien Laganier a écrit : > Now what your example essentially does is:
> - compile an old library on an old system without the > new API so that is conforms to the old ABI. > > - compile a piece of code on a new system with the new > API so that it conforms to the new ABI. > > - link the piece of code conforming with the new ABI > with a library conforming to an old ABI. > > Surprise: it breaks! Of course it breaks. I am well aware that there some systems have versioning capabilities and all to handle this... But, err, we are dealing with the system C library here! Breaking that means you have to rebuild and update the whole system (well, the C library, and every thing that depends on it, so almost the whole system). Very hard in general, and outright IMPOSSIBLE if you happen to support a platform with third party closed-source software. Continuing this way, you can be sure that some OS vendors will either not implement this, or do it in a non-standard way. With these considerations, it is much more practical to define a new API name. Besides, since in anycase, addrselect-aware applications and libraries will need source code modification, what is the problem with the latter approach? > Regarding the need for an application to save defaults > if it want to restore them, I don't see that saving > requirement as an issue. As we saw before, an > application has already many things to save (e.g. save > a value of the pointer to an addrinfo structure if it > wants to free it :) 1/ That's completely different. The addrinfo structure lifetime is much shorter than that of a network socket, both in term of source code path, and real time clock. 2/ That's not at all an excuse for *both* deviating from existing established practices AND making the API harder to use. That makes TWO (however minor that may be) inconveniences, with ZERO benefits. These issues were already raised more than 6 months ago. Are you trying to optimize for one specific vendor that would have already shipped a draft implementation ?? I have been asking for a rationale for as long, and still haven't received any sane answer. I really don't understand why you stick that hard to a broken design. In terms of spec work, it's very easy to fix; in fact, it would most likely make the spec shorter. -- Rémi Denis-Courmont http://www.remlab.net/
pgpkhG28TGhGZ.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
