On Mon, 17 Mar 2003, codemastr wrote:

> > Given that my vision becomes reality, you wouldn't have to care about
> > what DNS is or when libcurl resolves names etc. The multi interface
> > already provides mechanisms enough to work asynchronously, and I hope to
> > one day have DNS lookups embedded in this in the same way the
> > non-blocking connects are today.
>
> I know this isn't a feature that will materialize overnight, but I would
> certainly like to see it in the near future, and based on the fact that a
> few people have already responded to my original post, it seems like there
> would be many others who would like such a feature as well.

I'm sorry to say that the plain fact that many others would like to see the
feature become reality doesn't really help. What does help however, is code,
ideas, docs and donated sweat.

But if you're here to help out, I'm gonna do my best to not stand in the way
of your creativism. I'm with you.

I've talked about asynch DNS and libdenise issues every now and then for at
least a year, and each time the amount of people that have joined up on this
mission have been the same: zero, none, nada.

This is not a complaint. It is just facts; we are all limited by time and our
surroundings and we can only do a limited number of things, and I fully
accept that I spend an awful lot of more time on libcurl than anyone else. I
choose to do this volountarily! ;-) curl-stuff is my biggest hobby.

> The problem is, libdenise looks very promising, but, it seems to be at a
> very early state of development.

Yes, it still lacks big parts.

> They haven't even released a beta (or alpha) version. So presumably, you
> would want to wait until libdenise is stable before you add it to libcurl.

Well, I would add it early on and have people use a configure option to
enable it. Then the interested parties can test it early and report their
findings, without having to distburb the masses who don't care and only want
a stable and solid libcurl.

But yes, libdenise needs to grow and mature further before we go there.

> Then you would have to write all your code and wait till your code is
> stable. Since, looking at the libdenise CVS repository, there haven't been
> any changes made in the last 2 months, it would appear libdenise's
> completion is very far off.

That might be true, yes. But I can't see what else we can do but to cry out
for help even louder and spend more nightly hours on getting these projects
where we want them.

> This would mean implementing it within libcurl would be even further off.

Well, as soon as the API is somewhat settled and functional, we'll implement
it in libcurl. Then we'll work on both ends in parallell to get the
functionality set. That's at least how I've imagined things to evolve.

> Like I said, I'm sure this isn't something we'll see in the next few weeks,
> but I would hope it would be available say within a year. Using libdenise
> it doesn't look like that would be a reality.

Again, I don't have or see any alternatives. If we were just a few more
active authors on these projects, then we could accomplish a whole lot in one
year. But I don't expect any major changes around the corner.

> Well thinking about this more, I realize most of the reasons I was thinking
> of could be implemented differently. I was thinking things such as set a
> DNS timeout, set # of DNS retries, tell it to only retreive AAAA (IPv6
> only) tell it to retreive only A (IPv4 only), but these kind of things
> could easily be implemented within curl_easy_setopt as a new set of "DNS
> Options".

Aha, yes, I would like to see them set using the ordinary libcurl APIs.

[ from another mail by codemastr on the same general topic ]

> > libdenise exists only because we have yet to find an asynch DNS resolver
> > that isn't GPLed and that is good! The moment we find one, we can dump
> > libdenise!

> Have you considered talking to the authors? Maybe they'd consider switching
> to the LGPL (which if I remember correctly would make it ok for you to
> use). Maybe if you explained to them why it would be better to use LGPL as
> opposed to GPL they'd consider.

I've actually tried that route as well. One not-to-be-mentioned author of one
of the alternatives struck down on me like a madman with flames and ended up
threatening me with legal actions if I ever would contact him again. I am so
incredibly stupid to claim that anything besides GPL to be free software and
the very idea of having code not using GPL should be banned world-wide
yesterday already. (Ok, I agree this wasn't really relevant here, I just felt
like telling you about it!)

Those attempts have failed as well. Besides, I'm afraid LGPL isn't "good
enough". (This is not a license war, let's stay away from this topic. We've
had it before.)

> But as far as adns goes, adns seems to be a poor choice. It doesn't support
> Windows, it doesn't support IPv6, and it seems to be pretty much a dead
> project. You'd wind up rewriting so much of it it would be easier to write
> your own library.

Oh, I didn't know.

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en