<html>
<head />
<body>
Hi David -<br /> <br /> Are these patches needed only for IPv6 or also to support IPv4? If the latter, this would bother me greatly. I can understand why IPv6 may be implemented in incompatible ways but I can't see why there should be an incompatible interface to IPv4 addresses which have been used for eternity in Squeak. In particular given that (I believe) SocketAddress is a subclass of ByteArray it strikes me as not particularly hard to have Sockets support ByteArrays of length 4 as IPv4 socket addresses (and perhaps return instances of SocketAddress with length 4 or so). In any case, I'm not looking forward to seeing every last bit of networking code break - there has to be a better way...<br /><br /> Cheers,<br /> - Andreas<br /><br /> <blockquote type="cite">
<p>-------- Original-Nachricht --------<br />Datum: Sun, 15 Jul 2012 11:46:54 -0400<br />Von: "David T. Lewis" <lewis@mail.msen.com><br />An: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>, andreas.raab@gmx.de<br />Betreff: Re: [squeak-dev] WebClient test fails in trunk<br /><br /></p>
On Wed, Jul 04, 2012 at 11:46:58PM +0200, Levente Uzonyi wrote:<br />> On Tue, 3 Jul 2012, Frank Shearar wrote:<br />> <br />> >On 3 July 2012 17:42, Frank Shearar <frank.shearar@gmail.com> wrote:<br />> >>On 3 July 2012 17:38, Levente Uzonyi <leves@elte.hu> wrote:<br />> >>>On Tue, 3 Jul 2012, Frank Shearar wrote:<br />> >>><br />> >>>>Hi,<br />> >>>><br />> >>>>I took WebClient for a spin in a trunk image, and found a failing<br />> >>>>test: WebClientServerTest >> #testServerDestroy throws a<br />> >>>>"ConnectionClosed: Connection closed while waiting for data". That<br />> >>>>sounds familiar - I think this was introduced in a recent Network<br />> >>>>change.<br />> >>>><br />> >>>>Still, it means WebClient needs fixing. I'll try fix it on my evening<br />> >>>>commute, but if anyone feels like racing me, I'll be happy!<br />> >>><br />> >>><br />> >>>Interesting, I had no issue with it on windows, except for some extension<br />> >>>methods trying to use the CrLf class variable in HTTPSocket (or some <br />> >>>other<br />> >>>class), but that variable doesn't exist.<br />> >><br />> >>Which reminds me of an important fact I should mention: I'm testing<br />> >>this on an Ubuntu Lynx box.<br />> <br />> The VM also matters in this case. I tried it with an older CogVM which <br />> doesn't have the new socket primitives.<br /><br />I wanted to check that the recent network updates were not causing<br />problems for WebClient. I found that some updates to WebClient are<br />needed to account for the fact that network addresses are now being<br />represented as SocketAddress rather than ByteArray when running on<br />a VM that supports the new network primitives.<br /><br />Attached is a change set that addresses all the issues that I could<br />find. I'm assuming that the testServerDestroy issue discussed above<br />has already been addressed, as I had no failures for that test.<br /><br />From the preamble:<br /><br /> Change Set: WebClient-networkPatches-dtl<br /> Date: 15 July 2012<br /> Author: David T Lewis<br /> <br /> These patches update WebClient to work with new network code in Squeak<br /> trunk (all tests green).<br /> <br /> Explanation: When using the new network code along with a VM that supports the<br /> IPV6 primitives, socket addresses are instances of SocketAddress rather than<br /> ByteArray. Conversion of a socket address to a string must be implemented<br /> differently for SocketAddress.<br /> <br /> Also use String crlf instead of undeclared CrLf in HTTPSocket class>>httpPostMultipart:args:accept:request:<br /> <br /> Note: Squeak automatically uses SocketAddress if the VM supports it at image<br /> start time. To force use of old style ByteArray addresses, evaluate<br /> NetNameResolver useOldNetwork: true.<br /> <br /> Follow up: The WebClient methods in HTTPSocket are marked as overrides (category<br /> *WebClient-HTTP-override) but are not overrides with respect to Squeak trunk.<br /> The override category prevents these methods from appearing in a change set<br /> fileout. Should these methods just be adopted in trunk?<br /><br />Dave<br /><br /></blockquote>
</body>
</html>