cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Curl-library digest, Vol 1 #786 - 11 msgs

From: Todd Fisher <taf2_at_lehigh.edu>
Date: Tue, 18 Mar 2003 09:25:30 -0500

I was reading on the libdenise page and noticed they rulled out mozilla
because getting at the code would be
difficult, but with mozillas most recent release isn't the GRE, Gekco
Runtime Environment, being used by
mozilla, meaning it should be easier to use this code in real
applications now andfor that matter isn't there
a lot of similarity between curl and what the GRE provides?

-todd

curl-library-request_at_lists.sourceforge.net wrote:

>Send Curl-library mailing list submissions to
> curl-library_at_lists.sourceforge.net
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/curl-library
>or, via email, send a message with subject or body 'help' to
> curl-library-request_at_lists.sourceforge.net
>
>You can reach the person managing the list at
> curl-library-admin_at_lists.sourceforge.net
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Curl-library digest..."
>
>
>Today's Topics:
>
> 1. Re: Asynch DNS (Daniel Stenberg)
> 2. Re: Asynch DNS (Philippe Raoult)
> 3. Re: Asynch DNS (Bjorn Reese)
> 4. Re: Asynch DNS (codemastr)
> 5. Re: Asynch DNS (Daniel Stenberg)
> 6. Re: Asynch DNS (codemastr)
> 7. Re: Asynch DNS (crpalmer_at_vivisimo.com)
> 8. Cookies and URL legal characters (Sigal Algranaty)
> 9. Re: 7.10.4-pre4 and ssl (Daniel Stenberg)
> 10. Re: Asynch DNS (Daniel Stenberg)
> 11. Segfault Error! (Nisan Bloch)
>
>--__--__--
>
>Message: 1
>Date: Mon, 17 Mar 2003 21:22:19 +0100 (CET)
>From: Daniel Stenberg <daniel_at_haxx.se>
>To: libcurl Mailing list <curl-library_at_lists.sourceforge.net>
>Subject: Re: Asynch DNS
>Reply-To: curl-library_at_lists.sourceforge.net
>
>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.
>
>
>

-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink?
You could win a Tablet PC. Get a free Tablet PC hat just for playing.
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
Received on 2003-03-18