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
