Martin "eto" Misuth:
It was experiment to see whether it kills all spawned "shell trees" when X goes away. Which it of course does. Maybe Mr Schmorp would be willing to implement feature to freeze shell instances in such cases? Who knows.

These so-called client-server designs for these things are fairly pathetic and hardly worthy of the appellation. The clients do little more than marshal up their arguments and environment, send those in a message to the server, and immediately exit. This is not really a client-server architecture. It's the architecture of WIN16, where programs would use DDE or whatever to forward secondary invocations to their hPrevInstance instances and then exit.

This is, of course, exactly what the userbase wants. The desire is not to have a client-server terminal emulator, or a client-server text editor, per se. The userbase wants a text editor or a terminal emulator where they can add tabs to an existing instance by just running a simple command.

Nonetheless, a design far more worthy of the name "client-server" would split the monolithic application in twain at some point. One obvious point, that relates to what you just said, is to have the display rendering in the client and the "being a terminal" part in the server. The display rendering could still be a multi-tabbed GUI window, with its own API for adding tabs via external program. But the actual terminal emulation part would not be tightly coupled inside that.

Designed that way, the idea of keeping the terminal sessions around when the display is not becomes a viable one.

Here's an off-the-cuff design using the console-terminal-emulator tool from the nosh toolset.

One would still have the main "terminal-server" process. When told to start up an emulation instance, instead of running that internally it spins up an on-the-fly "terminal-emulator" service bundle complete with a directory containing the input FIFO and display file, spins up an on-the-fly "terminal-login" or "terminal-shell" service bundle for the attached pseudo-TTY, and hands them both off to the per-user service manager to run and to manage. (For an idea of what such service bundles would look like, see the "terminal-emulator@vc1" service bundle for a system-wide terminal emulator and the "ttylogin@vc1-tty" service bundle for a login service on that terminal, both supplied with the nosh toolset. One would have the device directory in some per-user place like /run/user/$USER/dev/vcs/ rather than as it is done there, of course.) It can also attach to existing terminal-emulator services that are already running. On its front end, it would connect to one or more X displays and render the terminals as windows and tabs.

I'm not proposing to implement this myself, as I have more than enough to do, but I hope that it piques someone's interest. Here are some interesting facets of the design:

* console-terminal-emulator implements the terminal characteristics of the terminal emulator programs that are built into the Linux, FreeBSD/TrueOS, and NetBSD (and indeed SCO Xenix!) kernels. It doesn't have to be the only game in town. If one wants something that is closer to some other terminal type, then one just writes a different terminal emulator with the same input FIFO and display file protocol. The "terminal-server"'s knowledge of this is entirely limited to spinning up an on-the-fly service that invokes some other program than console-terminal-emulator.

* The relationship between the "terminal-server" and the underlying terminal emulators is many-to-one. There's nothing stopping this design from allowing multiple tabs or multiple windows to render the display of a single shared terminal instance.

* Further to the preceding point: Multiple servers, even. I already do this myself. The system-wide terminal emulator services such as terminal-emulator@vc1 can be "realized" on the console, using the framebuffer and HIDs, as well as simultaneously over (say) an SSH session using console-ncurses-realizer. The "terminal-server" in this design is just a fancy, GUI, multi-tabbed, multi-terminal, realizer and more of the same. One can connect, disconnect, and reconnect emulator services from multiple such "realizers" on the fly. I have.

* Further to the preceding point: With suitable permissions, a "terminal-server" could attach itself to one of the system-wide terminal emulators. So one could do things such as: Start up without X; log on on the system virtual terminals; do stuff; shut down console-fb-realizer and start up the X server; reconnect to the very same terminals with a GUI realizer program; continue doing stuff.

* The terminal sessions know nothing about the X display(s) and are unaffected by their absence. Of course the converse of this is that the terminal sessions know nothing about the X displays and in order to run GUI programs one has to explicitly set a DISPLAY environment variable. On the gripping hand, we are talking about spinning up service bundles on the fly. There's nothing stopping the "terminal-server" program writing its selected DISPLAY into the env/DISPLAY of the "terminal-shell" service bundle, to give things an initial leg-up.

* There's a distinction between closing a window and stopping the terminal session. So one would have to add some way to stop terminal sessions. The GUI would gain a "hangup" menu option or some such. The input FIFO and display file protocol that I currently have doesn't incorporate the idea of the realizer triggering hangup. It was designed as a replacement for the in-kernel virtual terminal subsystems, where terminals don't get hung-up from outside, because *there is no* outside. There's no serial device with a carrier detect signal. However, note that "system-control --user hangup terminal-shell@5" (or "svc -H", or indeed their equivalent using the supervise/ directory API directly) is of course a valid way for the "terminal-server" program to approach this.

Reply via email to