I for one never said we should throw out the new network code. But, we've been living in collective denial trying to reduce it to one defect when it is actually more complicated than that. Having cited the over-use of inheritance of the Squeak image as a source of various problems, I will add that inheritance *should* be used in NetNameResolver - specifically, we should group the ipv4 and ipv6 primitive sends into protocol-specific subclasses. Errors that are now weird-looking primitive failures will suddenly become DNU errors with an obvious cause. We should further send SocketAddress to its reward and make any required changes to use an aspect-based address that can lazily help with name resolution, and does not drag the port number into the address. The socket primitives will have to change at the same time (I think). IMHO, the only quick fix is to go back to known working network code, at which point we can plan for IPv6 in a future milestone. I urge the next attempt be based on an improved design, hopefully one that will allow OpenSSL sockets along with the usual suspects. 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: Friday, January 29, 2010 7:23 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508? On 1/29/2010 1:08 PM, Adrian Lienhard wrote:
Do I understand correctly?: ipv6 issues are a VM problem, hence not directly related to Pharo. But #useOldNetwork does not work as advertised in new network implementation because it still uses ipv6 code/primitives.
Hence, should we just roll back the network changes and use the old code as in Squeak 3.9, which, as far as I can tell, works well?
Apologies for coming in a bit late into the discussion. The new network plugin/code was orignally done by Ian and mangled by myself (with contributions by Bert and Yoshiki IIRC) to be used in etoys as OLPC is IPv6 only. So would be worthwhile checking the etoys network code. Idea behind getting the code into Pharo was to enable more than the really outdated and bare bones network access available through the old network code. That the new stuff still doesn't work is a shame, but IMHO we should fix it rather than throwing it out. Patching the current code to allow use of the old network stuff would buy us time to fix the new code. Michael _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project