On Mon, 23 May 2011, Bert Freudenberg wrote:

>
> On 21.05.2011, at 01:52, Levente Uzonyi wrote:

snip

>>
>> Okay, I got it, but what will happen if I save an image with SocketAddress instances on Linux and open it on Windows? Will it crash if I try to use those SocketAddresses?
>
> I don't know. SocketAddress instances are supposed to be temporary, IIUC, application code would not store them.

Ok, I'll take a closer look at this.

>
>>>> 3) SocketAddress lacks setter methods, so implementing compatibility methods, like ByteArray >> #asSocketAddress is a PITA.
>>>
>>> It's platform-dependent. You need to call the primitives to create proper SocketAddresses. That is encapsulated in the class SocketAddressInformation. See e.g. forHost:service:flags:addressFamily:socketType:protocol:.
>>>
>>> Btw, there is a method ByteArray>>#asSocketAddress. There are only two senders, it is only used when useOldNetwork is true. Not sure why this needs to be there. We could ask Michael what the idea was. I guess we could get rid of it.
>>
>> Existing code (e.g.: all senders of Socket >> #connectTo:port:) uses ByteArrays where the new socket code expects SocketAddresses, so these conversion methods are mandatory.
>
> #connectTo:port: has been changed to use either the old or the new socket code.

That's right, but if my package has the following code:

Socket new connectTo: #[127 0 0 1] port: 12345

and I the image uses the new socket code, then I'll get an error, because 
the ByteArray is not a SocketAddress.

>
> Anyhow: are you suggesting the extended SocketPlugin is completely useless, or that we should not use Michael's new in-image code?

No, nothing like that. We should only make sure that it's compatible with 
the current socket API.


Levente

>
> IMHO the new primitives are a good foundation for the networking code to move forward. If we don't like how it's been integrated in the image, I would rather change (or even completely rewrite) that image code, encapsulating the new primitives as needed. But the plugin itself seems solid to me.
>
> - Bert -
>
>
>