The only thing I do not like is going back to when "addresses were just byte arrays." I think we should probably do that in the interest of time, but we in fact need to go the other way (certainly for 1.1), toward an InternetAddress class with aspects for address and host name (allowing lazy resolution in either direction). We should also separate port numbers from the address. Another thing we should do (again no later than 1.1) is separate the resolver into IPv4 and 6 subclasses to make it understandable. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Tuesday, March 09, 2010 4:39 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] networking problem (repost) On 3/9/2010 10:08 AM, Michael Roberts wrote:
So now my conclusion is firmly we have to take a step back and simplify. for pharo 1.0 unless we have someone with a lot of time i do not feel we can untangle the resolver and socket code. We should
As the one originally being responsible for integrating the new socket code I'm voting in favor of this solution. The new socket code was initiated in the OLPC project and I was (falsely) assuming that it it would be stable and/or be maintained to a satisfactory level. So either the OLPC people have fixes that we don't know about (just looked at the latest etoys image and the code seems to be the same) or it just happens to work for them. Or people using the etoys version simply don't do anything exciting with the network. Michael _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project