sequences for TE data actions

[jerch]

The following rough idea might seem pretty wild at a first glance, but could turn a TE into a swiss army knife for remote administration tasks of stripped-down target machines . The idea in fact borrows some concepts of intelligent terminals of the 80s, but with a different interface idea (TBD, not strictly limited to the terminal view).

Idea
Extend the terminal API by sequences introducing a document/dataset + action concept. The sequences will allow the TE to exchange annotated data from any data source on application side (e.g. a file, a pipe etc) and do something with it on TE side. Getting any data is already possible with cat but has low to no usage, as it just spits out the data into the terminal buffer. Typically preinstalled client apps come to a rescue here, but what if we would move that client logic to TE side instead? Quick examples:

• text files: instead of loading into preinstalled cmdline editor, load dataset into TE marked as editable text, which triggers a load into a TE local editor with the option to save back changes (could be monaco for xterm.js)
• PDF files: transfer data to TE side and open in attached PDF viewer (could be pdf.js for xterm.js)
• SQL query: could embed the database connection protocol to reroute IO to a full featured SQL-IDE on TE side without the risk to open the SQL connection to the outer world or the need to set up complicated 3rd-party bridging tools

I am pretty aware that there are already tons of tools or other protocols to achieve the same goal, the convenience bonus here mostly comes from:

• re-utilize the already established terminal connection for more than just typed input and cmdline app output forwarding
• implicit actions (configurable on TE side), instead of doing things like: open 2nd connection / extract/copy data / view/edit locally / re-upload changed data
• tech stack requirements move from target machines to TE host (which devs typically have under perfect control), avoids the infamous situation "Eww, there is no vi installed, how am I supposed to view/edit this config file?"
• various actions thinkable, like view/edit/upload/download data

Audience
This is mostly directed towards sys admins (or in new business-speech "sysops"), that have to deal with different remote system setups, where a more clever handling of various datasets on TE side might be a relief for everyday tasks. It is def. not much of a help for mostly local terminal usage, so overall benefit might be limited. Therefore I'd like to hear opinions on that early idea first, before inventing a square wheel. Feel free to enhance or completely debunk the idea, esp. regarding possible pitfalls like security aspects.

FYI: @Tyriar, @meganrogge, @mofux, @textshell, @christianparpart, @j4james, @hackerb9, @PerBothner

[j4james]

Could this sort of thing not be achieved with something like the sz/rz protocol (zmodem?). The terminal would just need to give users an option to configure what happens when a file is received. Typically this would be a "save to disk" prompt, but I don't see why it couldn't be configured to automatically open certain file types in a client side editor.

I'm not sure about saving, but maybe if the terminal monitors the local copy of the file for changes, it could also provide the option to upload those changes back to the source.

I haven't used this sort of thing in decades, so my understanding of things may be wrong. But if there's an existing protocol that is reasonably applicable, I'd definitely prefer that over inventing something new.

[PerBothner]

Are you thinking of a protocol to handle all 3 of your examples? That seems difficult. Or perhaps a framework for a family of protocols?

You first example seems reasonably doable. You would have a command like open-on-server FILENAME (where "server" is used in the X1 "display-server" sense - i.e. where the human user is). This could transmit the name and contents of FILENAME to the terminal, which can do a "open /tmp/FILENAME in user-selected application". The open-on-server command could take an option to specify an application (though that has more security issues). The open-on-server could have two variants (perhaps based on a switch):

• Open read-only. The open-on-server command returns immediately.
• Open for modification: The user-local application can edit the file copy. When the user saves a change, the file is copied back. The open-on-server command has to wait until the application closes.

Is that the kind of thing you had in mind?

[jerch]

@j4james Oh you got me here, the idea is in fact a spinoff from my current attempt to get rid of modem protocols as the main driver for file upload/download for several reasons:

• they compete with terminal sequences on byte level (which is clear, as they were written for the modem layer, not a terminal as primary target/source), which introduces follow-up issues:
• cannot be embedded into terminal sequences (no intermittent transport possible, ambiguous state edge cases like the introducer can occur in normal terminal data by accident)
• needs a preparser state on terminal side
• needs a custom client on application side

So at the core the idea above is indeed about how to transport data safely between terminal and application side, but in a more terminal friendly way. My current not yet published protocol attempt for this completely relies on POSIX coreutils (no need for a custom client app) with the help of shell functions to be used like this term_dl < some_data_source and term_ul > some_data_target. But I soon figured, that a proper sequence foundation would also allow a term_edit or term_view just the same way, hence the more generalized idea here.

Typically this would be a "save to disk" prompt, but I don't see why it couldn't be configured to automatically open certain file types in a client side editor.

Yes, thats the gist of the idea. In the end, actions should be configurable on TE side, and allow to retrieve or send data from/to application side.

@PerBothner

Are you thinking of a protocol to handle all 3 of your examples? That seems difficult. Or perhaps a framework for a family of protocols?

Indeed the third example is an extreme, as it would extend the idea even to bi-directional streams. My zmodem replacement currently supports multiple up- or download sources running concurrently (ofc it has to be in-band serialized), so per se I see no reason, why it should not be possible to handle bi-directional streams as well. True - that might need a much broader spec foundation possibly leading to a family of sub-protocols (have not yet put much thinking into the the bi-di streams).

Your open-on-server is basically what I do with my term_dl / term_ul functions currently, but with a broader scope. The blocking nature of that command is indeed crucial to have proper chunked/pipe support.

The open-on-server command could take an option to specify an application (though that has more security issues).

Yeah this prolly has to go through a TE defined mapping to avoid calling into some random app as told by application side. What might work here (not thought out yet):

• TE holds a user defined map of actions, e.g. {'view_pdf': 'call local pdf viewer to some temp resource managed by the TE', 'stream_postgres': 'point to local socket or local postgres client, whatever works here...'}
• on connect to remote host, shell gets extended by functions from those names, e.g. term_view_pdf, either magically (TE figures out shell and places these functions automatically) or by explicit user action (copies snippets over, thats what I currently do for my up/download functions)
• now the user can freely use these shell functions like normal shell commands

What always should work here too - write a big fat cmdline app. This has the downside of the additional install step, but also some pros like being able to use the PTY transport in much faster raw mode (thats very limited with shell functions, many coreutils are very line centric as I had to find out), or being able to do an early libmagic content deduction on application side (not sure yet, if such an automagic functionality is a good idea).

[jerch]

Regarding the POSIX utils compat part:
I currently strive to stick to this list of commands https://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html and commands supported by the reduced shell of BusyBox (https://busybox.net/downloads/BusyBox.html) as the least denominator.
This already creates some frictions regarding ASCII printable encoding of binary data - uuencode/uudecode is listed in both, but so outdated that even my standard ubuntu install does not contain it anymore out-of-the-box. What I found to be available on most systems instead is base64, therefore I use this atm.
For the more complicated line and chunk handling I currently use awk, which is available on all systems I have tested. It is also much faster than doing the line processing in the shell itself. Interpreter like Python or Perl are less likely to be found preinstalled, so awk seems to be the only option for an as close as possible POSIX fit.
My chunked protocol also contains a checksum option (similar to zmodem), but refers here to CRC32-POSIX to be in line with the default algo of the cksum command.

[j4james]

they compete with terminal sequences on byte level (which is clear, as they were written for the modem layer, not a terminal as primary target/source), which introduces follow-up issues:

Again I haven't worked with this stuff in a long time, so I'm not sure how complicated it would be to implement, but I know there are a number of terminals that have sz/rz support, so it's definitely possible.

Also it's one of the most popular feature requests for Windows Terminal, so if it is possible, it's quite likely we'll implement it at some point. And once we have that, I can't imagine there'll be much demand for an unknown protocol that does more or less the same thing.

needs a custom client on application side

But if I've understood you correctly, your proposal would require a "custom client" as well - it's just in the form of a script limited to POSIX coreutils. If that's the only selling point, I'd be more inclined to just paste a uuencoded binary onto the system.

Anyway, I'll leave it at that. I'm not particularly interested in the idea, but don't let me stop you.

[jerch]

@j4james Well, you will run into several state ambiguities with zmodem up to a point where you have to parse heuristically and dispatch the data either to the zmodem or the vt parser. I am sure you will figure it yourself once you get at the protocol byte level, it does not blend at all with VT sequences. And the fact that zmodem is used by some TEs does not make it a good choice per se. It is more for historical reasons, when modem usage was still a thing.

If that's the only selling point, I'd be more inclined to just paste a uuencoded binary onto the system.

As I wrote above - uudecode is not available anymore on all systems by default. Sure you can also use base64 here, but then what about ABI compat? And all these hassles just to stick to an VT incompatible protocol?

Edit:
And nope, thats not the only selling point. The idea here is to shape a protocol, that allows intermingling of several data transports and normal terminal IO, which is not possible with zmodem (comes as a foreign blob of data in the IO stream).