Skip to content
This repository has been archived by the owner on Aug 19, 2021. It is now read-only.

websocket mode #51

Open
flying-sheep opened this issue Feb 17, 2014 · 5 comments
Open

websocket mode #51

flying-sheep opened this issue Feb 17, 2014 · 5 comments

Comments

@flying-sheep
Copy link

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”.

@pyhedgehog
Copy link

-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.
However you are right, that some message-oriented (or even object-oriented) protocol would be very usable. What about CORBA? It's object-oriented. It's cross-platform. It has libraries for almost every sane programming language (C, C++, Python, Perl to name a few). It would be very pretty to create XPCOM<->CORBA proxy generator. However this doesn't fit to this project scope.

@flying-sheep
Copy link
Author

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.

@pyhedgehog
Copy link

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 (int execString(in string input, out string output)).
Why not use some human-readable message-passing protocol like used by FTP/MemCache?

@flying-sheep
Copy link
Author

It's comprehensible and elegant

hmm, right, this suggests it’s better than thought because it suffered from bad implementations.

Why not use some human-readable message-passing protocol like used by FTP/MemCache?

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!

@pyhedgehog
Copy link

All I want to say - I need to keep ability to connect to it with telnet or socat.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants