Implement SocketPlugin

[codefrau]

So far, there is no networking support (except via the JSBridge). It would be awesome if socket connections could be opened, but it's not quite clear how this could work. WebSockets are a possibility but are hampered by the browser's security restriction. Possibly a proxy server is needed.

[ccrraaiigg]

Yes, a proxy server is needed. I'm writing WebSockets support for Squeak on all host platforms, including SqueakJS. It supports transparent operation of the Flow networking API.

[codefrau]

As of 94c003a we have a client-side only SocketPlugin using a public CORS proxy. It only supports http/https requests. So I think a WebSocket-based client+server solution is still needed, to enable non-http connections.
Do we want to ship two different SocketPlugins? Or merge them into one?

[ccrraaiigg]

I think we should merge them into one. The networking support I mentioned is now part of another project that includes remote messaging, screen-sharing, and a new way of installing native Squeak. While those special cases have priority over transparent generalized socket use (similar to the image-updating case), I estimate having something separable in August.

[ErikOnBike]

I have updated the SocketPlugin with WebSocket support. It is working in my current setup (on NodeJS and within browser) with Cuis. Some more testing is needed with different images as well as some extra guards need to be build in. I do have a few questions though:

• Within original SocketPlugin the primitive methods sometimes do popthenPush(argCount, ...) and sometimes popthenPush with some literal number. Shouldn't this always be argCount? If not, what is the reason? See for example primitiveSocketSendDataBufCount where argCount === 4 but popthenPush(1, ...) is performed. (This also happens in a few other plugins.)
• What is the reason for using both fetch(...) and XMLHttpRequest? It does not seem to be for supporting old browsers, since fetch seems similar in support as TextDecoder and TextEncoder which are used without a replacement.
• I have also added name resolving in the SocketPlugin (using DNS over HTTPS). Would it be okay to receive this in a single PR or do you prefer separate PRs?

@ccrraaiigg maybe this is useful for Caffeine as well.

[codefrau]

Awesome! I'm really busy atm, so can't review in detail, sorry. But as to your questions:

• Yes, we should use argCount consistently. If the primitive checks that argCount is the expected value then that is unnecessary, but it also doesn't cost much.
• fetch vs XMLHttpRequest is just historical I think. We started out XMLHttpRequest but then fetch had some advantages, I think regarding CORS. It would be fine to get rid of XMLHttpRequest
• single PR would be fine

[ErikOnBike]

I think this issue can be closed. If getting rid of XMLHttpRequest is relevant, maybe we should create separate issue for it. (Would clean things up in SocketPlugin ;-).