Fake socket that doesn't need serializing/deserializing

[martinRenou]

Currently, the mock-socket's WebSocket needs a string to be passed through the "fake wire". This means we need to serialize messages, pass them through the wire, then deserialize.

Instead, it would be faster and more robust to be able to pass the original message through, without any serialization involved.

[martinRenou]

This is more or less a copy of WebSocket.send only that it doesn't force the data to be a string

[martinRenou]

Instead it passes the KernelMessage.IMessage without touching it

[martinRenou]

It's in a non-working state. I am opening this PR so that we can discuss it.

[jtpio]

Thanks Martin for exploring this 👍

There is definitely room for improvement at the message passing level. For now mock-socket has been working ok, but maybe there is also a bit of refactor that can be done in @jupyterlab/services to make it easier for what we do in jupyterlite. Just an idea for now, but maybe that means making @jupyterlab/services or the ServiceManager more pluggable or make it possible to bypass the WebSocket completely.

[jtpio]

maybe there is also a bit of refactor that can be done in @jupyterlab/services to make it easier for what we do in jupyterlite. Just an idea for now, but maybe that means making @jupyterlab/services or the ServiceManager more pluggable or make it possible to bypass the WebSocket completely.

As a side note, we'll also probably want to have both in-browser and "normal" kernels supported at the same time. But that's something for another issue.

[bollwyvl]

This is a good step. There is a certain value in adhering as closely as possible to the WebSocket API, as some extensions will expect some of the plumbing to work exactly that way (even if they shouldn't). On that end, we should probably consider adding kernelspy to the demo site, and ensuring we generate content there, as losing the browser websocket playback, which just got good enough to use, is pretty crippling when you're building something and it goes wrong.

I'd love to eventually see a more broad embracing of native async generators on both the python and browser sides... i did a tiny bit of that over on #141. Definitely sounds like an upstream 2.0 (jp server) / 4.0 (lab) thing.

[jtpio]

we should probably consider adding kernelspy to the demo site

Sounds good 👍 Opened https://github.com/jtpio/jupyterlite/issues/197 to track this.

[martinRenou]

After further investigation, I think it doesn't work because we also need to mock the server-mock and proxy-factory, which both use normalizeSendData (the function responsible for forcing data type to string).

That seems like a lot to mock in the mock socket...