client-server desktop application design

From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups_at_NTLWorld.com>
Date: Thu, 8 Dec 2016 15:25:11 +0000

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_at_vc1" service bundle for a
system-wide terminal emulator and the "ttylogin_at_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_at_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_at_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.
Received on Thu Dec 08 2016 - 15:25:11 UTC