2008/11/26 Yang Tse <yangsita_at_gmail.com>:
> Hi Daniel,
>
>> Thinking even further, we could probably even rename the old
>> ARES_OPT_SERVERS to ARES_OPT_SERVERS_OLD and introduce the new
>> ARES_OPT_SERVERS with a new bit (and do similar with the 'servers' and
>> 'nservers' firleds) and then not break ABI (as existing apps will continue
>> to run), but recompiles will automatically use the new way...
>
> The problem is not on the ARES_OPT_* side, effectively if it was only
> located there something could be done.
>
> The root of the problem is that the ares_options struct is in the
> public interface since the pre-fork old ares days, and as such the
> library user is allowed to setup and fill with data an ares_options
> variable and feed it to ares_init_options().
>
> If the ares_options struct would have been private to the library and
> the library would have only exposed functions to manipulate it from
> the public API we would not be talking of this now ;-)
>
> But this is what we have, and this means that nearly any change to the
> ares_options struct breaks ABI.
>
> BTW the change to the ares_options struct committed 2008/11/01 already
> breaks ABI, and requires applications recompilation.
>
> So maybe this could equally be committed and do whatever other ABI
> breaking changes are pending, if anyone has any in mind, before
> release.
>
> My 2 cents
> --
> -=[Yang]=-
>
So perhaps, if the ABI is broken anyway, it's worth the time to *also*
make ares_options private and add manipulation methods? "Once and for
all", as it were?
Received on 2008-11-27