On Tue, 25 Jan 2011, Vsevolod Novikov wrote:

>> I think selecting resolver backend with configure is good enough. It's
>> already there and working
>
> Not there unfortunately.

Yes it is: --enable-ares and --enable-threaded-resolver select resolver
backend.

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

Supporting that kind of stunt will not be part of my goal for making the
internal resolver backend API cleaner and better. In libcurl we struggle hard
to keep and provide a stable and solid ABI and API to programs, but I really
do not want to put that restraint on us for our internal APIs. We need to keep
the right and ability to change the internals at our own whims.

Building with something external like that would indicate that we somehow have
a stable resolver-API and probably a rather stable include-file situation, and
I don't see very many upsides with that.

Sure, I understand how this can look as a good idea for your project and your
secret resolver, but I don't see much good coming out of it from the curl
project's view.

Therefore, if you want that external-resolver way supported, you should make
sure thay there's nothing internally that suffers from it. If so, I won't mind
having it. Let's first make sure we get a unified internal API done for it!

>> 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.

You didn't explain or motivate your changes at all, you just sent over a patch
against old code and I had to dig out these particular changes and question
you about them. That's not a very constructive way to discuss changes to our
software architecture.

> 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.

Of course. Simpler code is easier to test and less likely to cause problems.

But you can also turn around that logic and ask yourself: how many years have
the existing c-ares code been used and tested already using this concept that
you now suddenly want to change in an effort to bring simplicity? (ares
support was introduced in libcurl August 5, 2003)

I would claim that you increase the required amount of testing by this change,
not decrease.

> 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'm sure that no code anywhere is bug free. But I'm fairly sure that for most
use-cases the existing code is fairly good. A remake of the logic resets that
certainty and we need to start over.

Sometimes there's a need to do that reset, but this time you're also arguing
(as an example) FOR re-reading all the resolver config files for every new
request and I don't think that's a good idea and I expect that the more
performance-oriented guys will hit me over the head if I let something like
that slip in without it being very properly motivated, and I don't consider
"but it is simpler and easier to test" a good enough reason here.

>> I think we should allow the resolver backend to have a pointer/handle in
>> the SessionHandle struct

> 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'm sorry, I don't understand the meaning of that. What hooks/filters would a
resolver backend need and how would they work?

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

Great! You might learn that working against the git repo using git is the
easiest way to do libcurl development. It also makes it even easier for us to
receive and apply patches (git format-patch -> git am etc).

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html