-
Notifications
You must be signed in to change notification settings - Fork 64
websocket mode #51
Comments
-1. WebSockets designed as a ugly pile above http protocol to allow work from browser-restricted javascript. Adding support for it to MozRepl will increase risk of remote attack of local browser from remote-origin code. |
everyone who actually used CORBA at some point agrees that it’s horrible and luckily all but dead, but should have died faster. websockets would be implemented in firefox already, that’s why i had the idea to use them. they also have many implementations everywhere and command line clients exist. but if for some reason not websockets, how about ZeroMQ? It also has implementations everywhere (even e.g. in R), is not a horrible relic from business hell, and is widely used for things like IPython. |
I actually used CORBA and can't agree with you. It's comprehensible and elegant. However I can agree that it's usable for full-scale cross-process object bridge not for single-method interface ( |
hmm, right, this suggests it’s better than thought because it suffered from bad implementations.
this would have the advantage of not requiring libs or complex JS to emit and parse it. but wouldn’t it be nice to have a pretty usable console for it? i have an idea: how about adopting the ipython protocol? then we could have the notebook, a terminal shell, and a standalone shell window as frontends for free! |
All I want to say - I need to keep ability to connect to it with telnet or socat. |
how about replacing (or adding to) the ancient, text-based telnet protocol with websockets?
websockets have a concept of messages, so a command and response don’t ahve to be parsed from a text stream, but are simply sent and received with ws.send() and ws.onmessage.
only disadavantage is that a shell isn’t simply “rlwrap telnet host port”.
The text was updated successfully, but these errors were encountered: