[reSIProcate] [Patch] Sketch of patch for adding c-ares 1.5.x support

[Byron Campen]

	I agree that merging stuff into c-ares would be difficult, both from  
a "finding cycles to do it" and a "convincing the c-ares guys to take  
our changes" perspective. But, if we can get this tweak to the build  
system working/tested, it might give us a middle ground that'll make  
it easier. Plus, c-ares is an active project, with good distribution.  
I think it would be a good idea long term to move over to using c-ares.

Best regards,
Byron Campen

> Frankly, my inclination in the short term would be to rename our  
> symbols from "ares_" to "rares_" or something simple and mechanical  
> like that. I suspect a full merge of the functionality we need for  
> resip into c-ares would be a non-trivial task.
>
> /a
>
> Byron Campen wrote:
>>    Wow. So, it is my understanding that we've added a few unusual  
>> features to our copy of ares, that I'm not sure would be ready to  
>> merge back into c-ares. I haven't really touched our copy of ares.
>>
>>    Derek, what are your thoughts on this?
>>
>> Best regards,
>> Byron Campen
>>
>>> Hi.  I'm new to resiprocate, and from what I've seen so far, it's  
>>> one
>>> of the best SIP stacks I've worked with.  Nice work!
>>>
>>> I've run into one minor snag, though.  Our infrastructure here uses
>>> c-ares 1.5.x to do its asynchronous DNS lookups.  That library,
>>> maintained at <http://c-ares.haxx.se/>, has come a good distance  
>>> from
>>> the original ares library that is used in resiprocate.
>>> Coincidentally, I've contributed a few patches to that project as
>>> well.
>>>
>>> This wouldn't really be a problem, except the symbols used in c-ares
>>> and ares are the same: in both they all start with ares_, and in  
>>> fact
>>> they generally are pretty much the same.  So, this meant that I was
>>> maximally out of luck; if resiprocate or I had used any other DNS
>>> resolvers, we'd be fine to cooperate, but things are just too  
>>> similar
>>> to work :)
>>>
>>> Since c-ares has at least some IPv6 support and aims to work on  
>>> Win32
>>> as well as POSIX, I figured I'd solve this just by using c-ares
>>> instead of the contrib/ares that comes with resiprocate, thus this
>>> sketch of a patch in progress.  I'm hoping the folks on this list  
>>> can
>>> guide me towards a final patch that is good enough to include in
>>> resiprocate itself.
>>>
>>> What I've done so far:
>>>
>>> - Started with the 1.4 release (instead of svn) since I'm new to the
>>>  project and wanted to keep things simple.  Hopefully, there is
>>>  little volatility in this area, though.
>>>
>>> - Tried to hide almost all the differences between the library in a
>>>  new header, rutil/dns/AresCompat.hxx that is included only in .cxx
>>>  files.  In particular, the patch aims to not require including code
>>>  to define USE_ARES or USE_CARES in order to _use_ the library or
>>>  its headers, although a built library will be wired permanently to
>>>  one or the other.
>>>
>>> - Adapted the initialization and callback code to work with the
>>>  slightly new (improved?) c-ares API
>>>
>>> - Added rules to configure and the Makefiles to allow an external
>>>  c-ares installation to be used instead contrib/ares with minimal
>>>  pain outside of the rutil/dns/ directory.
>>>
>>> - Got things roughly working with the stack/ test tools.
>>>
>>> - Left some TODOs for things that are currently hard or impossible  
>>> to
>>>  do in c-ares, or that I didn't understand (see the patch)
>>>
>>> - Probably made a mess of it :)
>>>
>>> Clearly, the resiprocate version of ares hasn't stood still, so its
>>> version is also "a better ares", and so there are few things that
>>> resiprocate does that c-ares doesn't have support for right this
>>> minute.  The c-ares maintainers are good folks, though, so I'm  
>>> sure if
>>> there are any really important things that need adding, they'd
>>> consider it.  Even though I'm brand new to resiprocate, I'd be happy
>>> to help apply any patches to c-ares that would help make it more
>>> usable by the mainstream resiprocate version.
>>>
>>> As I said, I'd love to be able to get this draft patch to the point
>>> where it could be accepted into resiprocate.  Thanks in advance for
>>> any feedback!
>>>
>>> -- 
>>> ----------------------------------------------------------
>>> Brad Spencer - spencer at starscale.com - www.starscale.com
>>> <cares-support.diff>_______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>