On Tue, 2 Dec 2008, Brad Spencer wrote:
>> ares_set_*() style functions that set (new) config options. As a start we
>> simply add these for new functionality, but over time we can also introduce
>> them for existing "struct ares_options" so that we can eventually deprecate
>> the two ares_*_options() functions.
>
> Reading the feedback on this idea, it struck me that maybe some of the use
> cases I have weren't obvious. Right now some of my stuff (and resiprocate)
> is using ares_save_options() in order to simply inspect the configuration to
> do things like:
>
> - print out the DNS servers being used on a newly initialized channel
>
> - compare the lists of DNS servers used in two different channels to
> see if they are "the same" (for an application-specific definition
> of "the same")
>
> - similar inspection-of-configuration things
But none of these are reasons why ares_save_options() would be any better than
just keeping a channel handle around that you can read the options from.
The more important issue (which I can't stress enough) ares_save_options()
WILL NOT WORK since it'll return a struct that doesn't hold all config
options. To make it hold all config options we have to break the ABI every
single time we change it. None of these two alternatives are attractive to me.
> That's why I've been nagging about ares_get_*() methods, too :) I think
> there's been implicit acknowledgement :) that they are part of the proposal,
> but I figured I'd ask.
Yes, they are part of the proposal, but I'm not pushing that part since I'm
not myself seeing anything major I'm personally in need of. I think we add
them (the ares_get_*() functions) when people provide the code for them.
And I'm not saying we actually deprecate ares_save_options() until we have an
alternative that works (better). For all I care we can keep the function
around basically eternally.
-- / daniel.haxx.seReceived on 2008-12-03