Re: [Gaim-devel] Resolving IP addresses in Gaim

[Mark D. <ma...@ki...>]

Nope, this is completely unrelated.  We're discussing how to determine the IP
address of a given hostname in a non-blocking fashion.  We are NOT discussing
how to get the IP address of people in our buddylist.

-Mark

On Mon, 21 Aug 2006 22:02:06 +0200, thomasasta wrote
> If you would code http://Cspace.in into Gaim
> it would be possible to get from each buddy the IP adress
> which is actual, as the RSA-Key is found in the Kademlia base,
> You only need to stick the RSA-key in the gaim client to any other 
> Chatname of any other protocol. With this method you can look up in 
> each session the actul IP Adress. And you could do even more, the 
> file transfer mechanism is for each protocol differen, you could, if 
> in the client the Chatname of each protocol is stuck to the Cspace-
> Rsa-Key, use the Cspace protocol to have UNIQUE filetransfer to each 
> GAIM users. Does this solution solve your problem to get the IP 
> adresses of the users? While AOL and MSN .. etc do not allow 
> directly the IP adress pining of a buddy - jabber i do not know -
>  Cspace can provide them... How is Libc doing it ? Kind regards...
> 
> -------- Original-Nachricht --------
> Datum: Mon, 21 Aug 2006 15:43:52 -0400
> Von: Ethan Blanton <ebl...@cs...>
> An: gai...@li...
> Betreff: Re: [Gaim-devel] Resolving IP addresses in Gaim
> 
> > Sean Egan spake unto us the following wisdom:
> > > Considering the DNS lookup code is already written, tested, and
> > > stable, I see no compelling reason to screw around with it too much
> > > now, but I'm not too particularly concerned.
> > > 
> > > Really, we should just extend our SRV lookup code to handle A records
> > > asynchronously.
> > 
> > This has been discussed before, and there is a good reason we have
> > not.  Namely, gethostbyname() [getaddrbyname(), whatever] does _not_
> > necessarily just do a DNS lookup.  Hostnames can be served from
> > /etc/hosts, from NIS, from NetInfo, from LDAP, from WINS, from [...].
> > We obviously aren't going to write mechanisms for all of these things,
> > so it's best to leave it up to libc.
> > 
> > Ethan