| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
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@xxxxxxxxxxxxx - www.starscale.com
Attachment:
signature.asc
Description: Digital signature