WebTerminal Over Telnet Is Possible. Should It Born? (v5) Open Discussion.

[nikitaeverywhere]

This discussion is open to anyone who use or know about WebTerminal project. It is a result of a long story of the project development, testing and maintaining.

While WebTerminal greatly improves user experience by enhancing standard terminal with additional features, there are numerous issues (#77, #92, #81, #87 and others) showing that it performs not as expected in some cases, and does not support some very basic things (like $ZA/$ZB variables). The reason is in fact that WebTerminal project tries to reimplement Caché TERM behavior over Caché ObjectScript capabilities. And it turns out that it is not always possible (see, for example, #77 or #92). The "built-in" Caché TERM features like programmer mode or debugging are very hard or even impossible to re-implement either.

The one possible solution I am thinking of more and more, is to build WebTerminal over Caché TERM, keeping all WebTerminal's goodies (and, of course, the web part) in place. As one capable approach I see telnet (special thanks to Stephen, who opened #100). I already made some tests and I can confirm that it is possible to transfer WebTerminal engine onto telnet without any changes from the user side.

From the user point of view, nothing will change, except of WebTerminal will start to support all terminal's basic stuff like programmer mode, debugging and correctly process F1-F12 keys as well as others.

From the technical point of view, I see the next workflow: terminal core class will open telnet session to local machine instead of handing all the commands using xecute. In this case WebTerminal code will start work as a middleware between "base" terminal session and a web user interface. All the current WebTerminal features are capable to work with this scenario.

I see the next major pros in WebTerminal "over" telnet:

• WebTerminal will support everything that terminal session over telnet do:
  • programmer mode;
  • debugging;
  • any programs written for Caché TERM and for the very old systems;
  • etc.
• WebTerminal will support connecting to Caché instances older than 2014.* via telnet from the web interface.
  • I think it will come as a new WebTerminal's feature, special command /telnet host@user:pass, for example.

But there is a one valuable cons I believe,

• Telnet service must be turned on.

I am always open to any suggestions and discussions. You can improve the project by sharing your thoughts here! Maybe there is a better "interface" to a Caché TERM rather than telnet, maybe you believe that re-implementing Caché TERM on Caché ObjectScript is not such a hard idea... Please, let me and others know!

Thank you.

[evshvarov]

Great idea.
Repost it on DC too.
I think we can substitute telnet to ssh in all the cases. telnet shouldn't be open on any server IMHO)

[tsafin]

When you invoke local (for Windows) Cachee' Terminal connecting to local Cache' service it's using named-pipes on Windows, there is no telnet involved. Telnet is died, forget about it, there is no sane person which would open telnet port just for the reason of better WebTerminal behaviour.

CacheTerm named-pipe protocol is simple, but undocumented, and I've no idea how named-pipe could be opened from within WebTerminal javascript proxy code, websockets not working this way.

So my advice - forget it...

[nikitaeverywhere]

Thank Tumur! Discussion on DC.

CacheTerm named-pipe protocol is simple, but undocumented, and I've no idea how named-pipe could be opened from within WebTerminal javascript proxy code

Oh that is interesting. No need to open pipes from JavaScript: if only I knew the way to open them from COS, then I can make it work with the browser.

[vsfan]

@ZitRos I am running into some issues with legacy codebase and some research led me here - tl;dr - I think the option to connect thru a telnet / ssh connection to cache instance will be a great feature. It will become immensely valuable in an enterprise environment where mixed versions of cache instances are run and as an admin person I can list 3 of them running 2012, and 5 running 2017.2 - oh wait, there is a hot backup which is at 2018 for testing of the upgrade. So please let me know if there is beta version I can test with - or if there is a dev fork you just need body. Thanks.

[nikitaeverywhere]

@vsfan thanks for your comment. For me, it's still the question of whether migrating WebTerminal to Telnet will be the right choice. I don't even know how telnet works over non-windows platforms, to be honest. #100 gave an idea that this is possible but I didn't go much deeper into exploring all compatibilities; I've tested that all escape sequences and known edge cases work as expected over the Telnet "pipe", comparing to the current implementation (xecute, I/O redirection, etc).

Note: this meant that WebTerminal can use Telnet connection under the hood to standardize the user experience and fix #77, #92, #81, #87 which are blockers preventing WebTerminal from running pre-historic terminal applications. If Telnet is 100% compatible with all platforms and yields the same result I'm okay with implementing it in WebTerminal. However, I still hope that InterSystems has some hidden undocumented "named pipes" under the hood which is the genuine solution for these issues.