PerBothner / DomTerm

DOM/JavaScript-based terminal-emulator/console

Home Page:https://domterm.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

question on telnet vs terminals sequence

thefallentree opened this issue · comments

Hi,

So, recently I started to work adding websocket support (with libwebsocket) to my application, which is an vitage text-based game engine, sort of behave like an multi-user time-shared terminal. The project use to deal with telnet protocol specifically, and it automatically turns on linemode and local echo during telnet negotiation.

In searching of similar stuff over websocket, I found xtermjs and also domterm. But it seems xtermjs specifically doesn't support any "telnet" client features, which means I would have to write line-editing support directly in my application.

I found this in DomTerm

"\e[80;97u"
"\e[80;99u"
"\e[80;108u"
"\e[80;112u"
Set input editing mode. The value 99 ('c') sets character mode; the value 108 ('l') sets line-editing mode. The value 97 ('a') set automatic mode, which switches between character mode and line-editing mode based on the mode of the inferior process (when using a PTY). The value 112 ('p' for "pipe") is like line-editing mode, but the inferiors doesn’t echo the input, so we have to do it. This mode is useful when the input is a pipe or some other non-tty stream.

Which seems to be doing what I wanted, but also it seems that it doesn't really belong to any sort of standard. Also, what would be the "mode of inferior process?" since I'm not really using an PTY. My question is, what is your suggestion?

  1. Should I stick to telnet protocol, and work on creating some telnet protocol handling in JS , write to transparent terminal emulators like xtermjs?
  2. Should I try to incorporate readline library into my engine and support editing and remote-echoing , directly writing to terminals like xtermjs ?
  3. Or should I switch to support DomTerm's non-standard line-editing mode directly in my engine? Which is better in your opinion?

Not only do I want to support raw domterm on an desktop computer, I may want to eventually support mobile clients with an webview or some other framing protocol .

Thanks

well, I agree the performance matters very little and it can always be improved, so it matters little in my case.

I know every terminal emulator has its own stuff, but in general xterm compatibility is enough, if an feature doesn't work on popular terminal emulator (xterm, iterm ) , it is very unlikely to be used anyway.

What I do want from domterm though, is following:

  1. distribute an consolidated and minified js and css. (built from master if release is not very often)
  2. an clear instruction on how to use domterm in an browser, connecting to a custom made WS backend.
    1. repl-client.html sort of does what it takes, but domterm-client.js contains too much stuff that I need to replace.
    2. make it clear what to expect from the backend, right now domterm sends a bunch binary handshake messages to backend, (for example .focus, .version etc) , either I need to implement those handshakes or if possible, domterm can support an standardized application level protocol (for example telnet, that allows linemode and local echo control messages)
    3. some js code to handle PTY related VT functions ( on sending \r replace it to \r\n , and on receiving \n replace them with \n\r) so websocket backend can be pure ascii input/output , no need to care about PTY stuff.

"distribute an consolidated and minified js and css."

I wrote some Makefile rules (using sed and patch) to combined the core .js files into a single file, removing the ES6 modules stuff. (Whether this is done will depend on configure options.) The resulting file can be compiled by Google closure-compiler, reducing the size from 495280 to 234523 bytes (for those files).

This still needs some polishing and testing but is promising.

Even better compression should be possible with "advanced optimizations" but getting those to work is more complicated.

webpack/babel is the way to go, I can help you set it up since I had some experience on frontend side as well.

see my comments on what is really need on xtermjs/xterm.js#2664 and let me know what you think

"webpack/babel is the way to go,"

What is the advantage of webpack/babel? For me Google closure-compiler has the advantage that it's trivial to install on Fedora (sudo dnf install closure-compiler) plus I had old (commented-out) Makefile rules I could update. So once I managed to concatenate the source files and strip out es6-module stuff it was very easy.

It should be easy to modify the Makefile to make use of some other minifier, if the benefit justifies it.