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

[Brad Spencer]

On Thu, Nov 13, 2008 at 03:05:25PM -0600, Adam Roach wrote:
> Brad:
> 
> While we work out what the best long-term approach here is, I've created 
> a branch that may work around the issue you're seeing.
> 
> It's suboptimal, inasmuch as you'll have two different copies of ares 
> linked in, but I think that's a necessary evil for now -- our ares has 
> stuff in it that c-ares almost certainly does not, and I presume c-ares 
> has stuff you need that our ares doesn't.
>
> What I've done is a fairly mechanical renaming of the #defines and 
> public symbols from the ares project that should eliminate conflicts 
> with c-ares.
> 
> Grab a copy from the repository:
> 
>  svn co 
> https://svn.resiprocate.org/rep/resiprocate/branches/b-abr-ares-rename
 
I will certainly give this a try and report back!  Thanks to you and
everyone for being so helpful!

> I really mean this to be a stopgap, but I don't want this relatively 
> small issue to get in the way of your attempts to use the stack.

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?
   
 - Is it relatively easy to enumerate all the important modifications
   to contrib/ares?  If so, if it would help, I'm willing to discuss
   them with the c-ares folks to see if c-ares has an equivalent or if
   they can be incorporated there, perhaps in a generalized form.
   Then, the number of features that are part of the caveat above
   might be minimized to a point that would make things more
   palatable.

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! :) 

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.

-- 
----------------------------------------------------------
Brad Spencer - spencer at starscale.com - www.starscale.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20081113/0a75f70a/attachment.sig>