Re: Revised address selection preference API draft-chakrabarti-ipv6-addrselect-api-04

2006-11-09 Thread Samita Chakrabarti
Hello Rémi, Thanks for your time reviewing V04 of the address selection API. Julien L. has already addressed your comments. Here are some additional comments. The proposed solution of extending the getaddrinfo structure (at the end) is designed to keep ABI consistency in mind. The extended

Re: Revised address selection preference API draft-chakrabarti-ipv6-addrselect-api-04

2006-11-09 Thread Samita Chakrabarti
This is all a matter of being consistent with the Advanced IPv6 API, and with the established practice in POSIX world. Pretty much every setsockopt uses int, unless it has very peculiar reason not to do so. Using something else will only confuse people, and add a (minor) extra implementation

Re: Revised address selection preference API draft-chakrabarti-ipv6-addrselect-api-04

2006-11-09 Thread Rémi Denis-Courmont
Hello, On Thu, Nov 09, 2006 at 07:45:29PM -0800, Samita Chakrabarti wrote : The proposed solution of extending the getaddrinfo structure (at the end) is designed to keep ABI consistency in mind. The extended ai_eflags will not break ABI boundaries unless the library design is broken.

Re: Revised address selection preference API draft-chakrabarti-ipv6-addrselect-api-04

2006-10-26 Thread Rémi Denis-Courmont
Hello, This is all a matter of being consistent with the Advanced IPv6 API, and with the established practice in POSIX world. Pretty much every setsockopt uses int, unless it has very peculiar reason not to do so. Using something else will only confuse people, and add a (minor) extra

Re: Revised address selection preference API draft-chakrabarti-ipv6-addrselect-api-04

2006-10-25 Thread Julien Laganier
On Friday 20 October 2006 14:48, you wrote: Hello again, Hi, For consistency with the current getaddrinfo and setsockopt usage, I think the preference flags ought to be an int rather than an uin32_t, What should we be consistent with? I don't understand how that would be more

Re: Revised address selection preference API draft-chakrabarti-ipv6-addrselect-api-04

2006-10-23 Thread Julien Laganier
On Friday 20 October 2006 14:41, Rémi Denis-Courmont wrote: Hello, Hi, Some random comments: Thanks for those; see my response inlined below: The proposed API adds a new IPv6-level socket option (IPV6_ADDRESS_PREFERENCES). IMHO, it ought to also specify that this can also be used

Re: Revised address selection preference API draft-chakrabarti-ipv6-addrselect-api-04

2006-10-23 Thread Rémi Denis-Courmont
Le lundi 23 octobre 2006 11:35, Julien Laganier a écrit : But this is specified (and somehow discouraged) in the Appendix: Doing per packet address selection would certainly be costly because running the algorithm isn't as cheap as setting a field in a packet. It surely is more expensive that

Revised address selection preference API draft-chakrabarti-ipv6-addrselect-api-04

2006-10-20 Thread Julien Laganier
Folks, I just resubmitted a revised draft on the address selection preference API incorporating comments and suggestions we got from reviewers (thanks!) since -03 went out last year. Until it shows up in the repository, you find it here:

Re: Revised address selection preference API draft-chakrabarti-ipv6-addrselect-api-04

2006-10-20 Thread Rémi Denis-Courmont
Hello, Some random comments: The proposed API adds a new IPv6-level socket option (IPV6_ADDRESS_PREFERENCES). IMHO, it ought to also specify that this can also be used as a non-sticky option through sendmsg() ancilliarry data, like other IPv6 options found in the advanced IPv6 API. It

Re: Revised address selection preference API draft-chakrabarti-ipv6-addrselect-api-04

2006-10-20 Thread Rémi Denis-Courmont
Hello again, For consistency with the current getaddrinfo and setsockopt usage, I think the preference flags ought to be an int rather than an uin32_t, and that resetting the socket option to system default should be achieved by passing -1 as the socket option value, rather than using