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]=-Received on 2008-11-27