2008/11/27, Daniel Stenberg wrote:
> Yeah, that public ares_options struct certainly makes it a bit too
> easy to break the ABI. It clearly seems we've already broken it so
> we better make the best of the situation.
>
> I can think of several different ways to improve ABI "survival rate"
> (in an order of increasing work amount):
>
> A very minor thing that would help is a "size of struct" field that
> ares_save_options() could use to work even with added fields.
Given the fact that a change, such as the IPv6 servers one, might
break ABI but actually not modify the size of the ares_options struct,
maybe it would be better to use a "struct signature" or "struct
version" member for this case.
> A somewhat bigger change is to require a particular ares function to
> allocate and return the struct, so that it could set internal magic in
> it too to deal with different sizes in the future etc.
Probably today isn't one of my best days, but I'm having real trouble
here trying to see how it would be done in this case if a change such
as the one derived from the "IPv6 servers patch" takes place.
> The biggest change would be to simply not expose the struct and
> introduce a ares_setopt() style function for setting specific options
> on the channel handle. This is the way we did it in libcurl and it has
> proven to be very good for maintaining ABI even when larger changes
> are done.
This is certainly quite a big change. The question is if there's
someone which really wishes to take on this. Maybe It could be
proposed as a 'Google Summer of Code' proposal.
-- -=[Yang]=-Received on 2008-11-27