Re: client-server desktop application design

From: Martin \ <et.code_at_ethome.sk>
Date: Thu, 8 Dec 2016 20:02:42 +0100

> On Thu, 8 Dec 2016 15:25:11 +0000
> Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups_at_NTLWorld.com> wrote:
>
> 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.

I am fully aware urxvtd was probably not designed with this usecase in mind,
but I was experimenting and left it that way afterwards. As former Windows
internals poker I am also aware of what you are talking about.

Still main design rationale behind urxvtd was, according to documentation,
to conseve memory and shrink new term window spawnage times, which it
properly delivers.

After some poking around I realised there is full pty implementation,
and theoretically it could, one day, do stuff as you describe.

Urxvt achieves many of it's stated goals, and I guess it's creation led to
creation of impressive ev event library. Those are great achievements.

>
> 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.

Well I would certainly welcome "tmuxlike" urxvtd server capable of holding
sessions operational while X restarts. Still there are not many terminals doing
properly even what urxvt does.

>
> 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.

This basically means you are doing something similar tmux does?

>
> * 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.

Yes that would be really nice, similarly with in-ssh session started
console-ncurses-realizer connections.

Unfortunately, we live in future, where writing "new cool terminal emulator"
means splatting pile of pinky goody feelie crap on top of braindamaged gtk vte
widget and declare it "job done". Or to have linux kmscon running, compiled
from git.

Also it seems tmux is already capable of many of these feats, so I guess there
is no perceived need to dwelve deeper.

I hope anybody who is toying with idea of changing emulator landscape for
the better, find and reads this, and evaluates some ideas discussed.

  eto
Received on Thu Dec 08 2016 - 19:02:42 UTC