On Wed, 7 Nov 2007, Shmulik Regev wrote:
> Recently there have been a couple of discussions regarding extra values
> passed to callback functions and the resulting API changes. We have also
> encountered a situation where we need to get data that is not currently
> available to the c-ares client (see below). Daniel mentioned (
> http://daniel.haxx.se/projects/c-ares/mail/c-ares-archive-2007-09/0023.shtml)
> that he thinks an opaque handle of some sort is probably the right way to
> handle (no pun intended) such future additions.
>
> My question - I'm willing to write such a patch but I want to understand
> what are the guidelines for it - should we use an handle and add calls to
> extract data from it or should we pass a struct that has the data?
It would then use the first approach, with some kind of function that extracts
information so that the (internal) struct can be modified between versions
without breaking the ABI.
> Oh, and the change we've made (to our internal c-ares tree) is : when a
> dns-query fails the client supplied callback function got the general
> ARES_ENOTFOUND error code but not the error code that was reported to the
> host_callback (in case of ares_gethostbyname for example). In our case we
> had a single name server that timed-out but we couldn't tell that from a
> situation where we've supplied the wrong IP for it.
I'm sorry, but can you elaborate on exactly why the existing value is not
enough? I don't quite understand.
I would also be interested in reading anyone else's opinions about this
patch/suggestion.
Related to this, I posted a blog entry about my current c-ares situation:
http://daniel.haxx.se/blog/2007/11/15/c-ares-and-me/
Received on 2007-11-15