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

Adam Roach adam at nostrum.com
Thu Nov 13 20:44:27 CST 2008


Brad Spencer wrote:
> As someone has pointed out, with my patch, the features that c-ares
> lacks will not be available.  Obviously, I won't presume to know
> what's best for resiprocate, but here are a couple of thoughts I had
> that might be worth considering:
>
>  - Imagine that some form of this patch was part of resiprocate.
>    Then, if a user elects to configure resiprocate to use c-ares, and
>    that comes with the caveat that not every feature of resiprocate is
>    available (at least at the moment), would that be acceptable?
>   

Speaking only for myself as an individual contributor, I'd be happy to 
see maintenance of ares handed off from the resip project to another 
group, as long as we can meet our requirements with an external project.

>    
>  - Is it relatively easy to enumerate all the important modifications
>    to contrib/ares?

Not without non-trivial research. You can get a blow-by-blow from the 
SVN log (svn log 
https://svn.resiprocate.org/rep/resiprocate/main/contrib/ares/), and you 
can diff between MIT ares-1.1.1 and the resip ares fork to get specifics.

On first blush, c-ares and resip ares have done a lot of the same things 
-- e.g., NAPTR and SRV support, different fixes to the same bugs, IPv6 
support, Windows and OS X porting, etc. As Derek points out, we've also 
added some unique features, like multi-lan failover for multihomed hosts.

> Of course, if resiprocate prefers to use only its own resolver that it
> can freely customize and control, I completely understand and take no
> offense! :)

As I said, I won't lose sleep over having someone else maintain ares for 
us -- but others may well have very different opinions.


>  
>
> I'll let you know how things go with the renamed branch as soon as I
> can throw together some trivial app using both resolvers.
>
>   

Thanks. There's a good chance I missed something somewhere -- let me 
know if you hit any collisions.

As an aside, many key resiprocate contributors will be AWOL next week 
(and several are this week) due to the impending IETF meeting. So you 
may get no or slow responses for the next couple of weeks.

/a



More information about the resiprocate-devel mailing list