Seems like a fairly simple patch to write and support. I'm thinking a
"populator" (which you seemed OK with) and a conditional around calling
the resolver or not if a flag of "CACHEONLY" is set or not. This patch
clearly wouldn't affect existing usage. It's completely optional and
isn't a performance hog. Yes I can obviously play games with the
resolving, but I was hoping not to, again alter system settings for a
library.

Your decision is most disappointing considering the simplicity of the
patch. This has merit in QA as well as all sorts of load testing,
"scriptable" interfaces, etc. It seems I'm considering more of an
enterprise approach, which clearly you aren't trying to address.

The search goes on...

Daniel Stenberg wrote:
> On Tue, 11 Jul 2006, Geff wrote:
>
>> I appreciate that point of view (/etc/hosts). However I was hoping
>> not to adjust the system settings (resolv.conf / nsswitch.conf / etc)
>> for a library.
>
> I can see how you were hoping for this and I can indeed sympatize for
> your case. Still, I gotta take a wider picture into consideration and
> ponder if adding this functionality is in the best interest of libcurl
> and libcurl-using applications.
>
>> So at this point I'm stuck with using the library as is or altering the
>> resolution properties at the system level.
>
> Yes, or applying your private patch. Or doing some fun link magic to
> replace functions to cause the resolves to fail. Or using chroot or
> similar to have your test environment execute in an alternative path
> where you can modify hosts and resolv.conf etc without affecting the
> rest of the system. Or providing a "spoofed" DNS server that can NAK
> certain resolves. Or...
>
> As I see it, you have quite a range of options to choose from.
>
>> If you're unwilling to take a patch to populate the cache and to
>> "CACHE_ONLY" resolve, please confirm that definitively. I don't want
>> to waste the time writing the patch if you won't take it.
>
> Right now I'm definitively against it because I don't see any good
> enough arguments for me to think otherwise, and also there's no one else
> to speak up for the inclusion of this esoteric option set.
>
> I'm always ready to reconsider my previous decisions if I get good
> arguments for it.
>
Received on 2006-07-12