> Would you be able to create and submit a patch for "our" version of ares
that
> fixes this problem?
Hmm I forgot that curl/libcurl was not GPLed. The code I included I released
under the GPL. I guess I wouldn't mind allowing that patch to be relicensed
for MIT/BSD (as long as the BSD version you are using is the GPL compatible
"modified" BSD license). I'll give it a go, shouldn't take too long.

>
> ADNS was dismissed (by me) as an asynch DNS alternative only due to its
> license. I've been struggling hard to keep curl and libcurl clean from
GPL,
> and I firmly believe that many of the libcurl users approve of this
mission,
> as libcurl is nowadays being used in many closed-source applications all
over.
> I'd hate to offer asynch DNS only to those who are willing to go the GPL
route
> of life.
I think you misunderstood me, I was not suggesting that you use ADNS or
FireDNS, merely that you look at their code at the "idea level". Meaning get
an understanding of what their logic was and then implement it using your
own code. I personally find reading someone elses code easier than looking
at half a dozen cryptic RFCs.

> So, while I'd be open to allow other libraries to be used instead of ares
for
> asynch DNS, I will remain wanting a working MIT/BSD library as well. No
one
> has volounteered to help me add support for any of those libraries yet,
and I
> don't expect it to happen. I'll personally remain working with ares, for
> license reasons.
I personally don't really care which library is used, all I want is IPv6
support. If you can get IPv6 support in ares then I'm happy.

By the way, this is something I was thinking of recently (sort of
unrelated). Some programs have "managed" sockets. What I mean by that is
they have a layer of abstraction they used with the sockets. What I'm
suggesting is 2 new callback routines. CURLOPT_SOCKETFUNCTION
CURLOPT_CLOSESOCKETFUNCTION. That way I can control the socket allocation
and use whatever I want. For me personally, my program has an array from 0..
FD_SETSIZE. Each item in that array represents an fd. If I am going to
allocate an fd for curl I have to do something like thearray[thefd].flags =
SOCK_INUSE|SOCK_LIBCURL; when the socket is created. I then have to do
something like thearray[thefd].flags = 0; when the socket is destroyed. So
basically, what I'm suggesting is give some callback routines. Then I can
just make a my_createsocket which calls socket(), updates my array, and
returns whatever socket() returned. The same idea would work for close().
I'm sure there are many programs out there that use their own socket system
just like mine does, so I think it would be beneficial if libcurl could have
the ability to work with such systems.

-- codemastr

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2003-09-14