Hi Daniel,

>> Not just replace, but be able to add a new one
>
> Right, that's what I meant: a new added one replaces c-ares as the one
> in use during requests as there's only ever one active at a time.
>
>> patching only those files which should be. Ideal solution is to make
>> it possible using configure script (or even runtime option) only, and
>> proposed patch makes such solution more available.
>
> I think selecting resolver backend with configure is good enough. It's
> already there and working

Not there unfortunately. I meant something like
./configure ... --with-custom-resolver=~/myperfectresolver/blablabla.c

> Right, but you've also sacrifised performance and the existing way of
> operating, so I wanted to know your reasoning for this. Your response
> here seems to imply that you had no reasoning at all.
The reason is complexity. I understand that the way which was introduced
by patch is a bit less optimal than present. The question is - what is a
size of this "bit"? On the other hand, presence of two data structures
with different life time, used in the same piece of code, introduces
additional complexity, and as such, requires much more tests to check,
whether the code works correctly in different circumstances.
> There is very limited name resolve testing primarily because it isn't
> that easy to do in a controlled manner (and we have no DNS test
> server), and secondary simply because we haven't had anyone work on
> that...
This is an additional reason to avoid complexity, discussed above. A you
sure that the existing resolver code of the curl is bug-free? Less state
volume, less time to live - less tests to check that all works fine.
> I think we should allow the resolver backend to have a pointer/handle
> in the SessionHandle struct for stuff that can be kept around between
> requests - as the c-ares code works today. And when that is used, the
> resolver backend also needs to be told when the dup_handle() function
> is called so that the resolver handle can be duped.
It was much more useful to have some number of behavioral and data hooks
which could be used to control custom intermediate filters on a way from
the URL requesting to data delivering. One of applications for such
hypotetic filters is - optimizing c-ares resolver storing opened ares
handler somewhere.

I will try to finalize a work on custom resolver in the developer branch
of curl.

Regards,
Vsevolod

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-01-24