Re: [reSIProcate] [Patch] Sketch of patch for adding c-ares 1.5.x support
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