Wayland - Beyond X (The H)

These problems aren't because the terminal protocol is serialized (network transparent), but rather because all interaction with the terminal is squashed into a single uncoordinated stream.

It's coordinated. You have escape sequences and about bazillion libraries which try to generate/interpret/parse them. The whole mess includes about ten thousand times more code (no, I'm not joking!) then simple buffer-to-buffer memcpy approach which worked perfectly fine on all computers starting from tiny ones like MSX (which had something like 32KB of RAM thus it quite literally had no power to even try to cope with all these libraries).

If you never used MSX then recall MS DOS. Things like Sidekick worked just fine there and newer created mess on screen. And the same is true on OS/2 and Windows.

And complaining about _input processing_ compatibility issues such as backspace appearing as ^H is just silly; the same thing happens on Windows terminals if you press unrecognized control sequences.

Only if program decides to show it explicitly. On Linux because of network transparency layer you get mess on your screen when you combine TUI programs in non-trivial form. You can only be sure that everything will work fine if you use simple programs which don't try to format output. Things like “"ls --color=auto” are not needed on DOS/Windows/etc terminal (they are needed if you want to store output in a text file and then process it as a text file, not as a terminal buffer, but that's different story).

The only difference there is that Windows only has one terminal type, which always defines backspace as ^H; Unix, with its richer history, is designed to be interoperable with many different terminal protocols.

Nope. That's because you don't need complex and convoluted logic to process data. If key comes to your program then it's Key Event or Mouse Event. If you write text on the screen then you write it on screen.

Easy, simple, reliable. Not flexible, that's for sure (it's not easy to get “screen output” of one program and interpret it as “keyboard input” for another program). Basically in DOS/Windows/etc you have solution which solvers perfectly most popular cases and is almost totally useless for less common cases while in *nix you have solution which does everything... poorly.

Wayland vs X is the same story: you can use Wayland to do things which are very easy, simple and power-efficient (things like complex scrolling effects which are demanded by Joe Average who've seen iOS or Android) but other things (like network transparency) are hard to implement (if they are possible at all).

What will you prefer? It depends on what you want to do, really.

You're complaining about artifacts of the VT-100 terminal protocol, not anything inherent in network transparency.

Actually that's both. These are artifacts of VT-100 protocol which are typical for a systems with “efficient network transparency”.

I don't think anyone would argue that VT-100 is an ideal arrangement, but its flaws are not applicable to network-transparent protocols in general.

Sadly they are. When you see garbage in your console and when you see overlapping text in your [remotely served] Firefox it's the exact same failure: bugs and inconsistency in unnecessarily complex (from local use POV) protocol which is inconsistently/buggily implemented.

Imagine for a moment, if you will, a serialized terminal protocol consisting of a series of atomic (row, column, style, character) quads. This protocol would be perfectly network-transparent, yet would also be indistinguishable from the direct access you're advocating--the quads and direct writes to the buffer being perfectly interchangeable.

Well, sure. This is VNC-like remote display protocol advocated by Wayland developers.

You can even do this with the existing VT-100 protocol provided you have exclusive access to the terminal and don't mind wasting some bandwidth constantly resupplying position and style information the terminal already has.

You can not. You can write one such program, but it'll be exercise in futility because all other programs expect to use "network-transparent" VT100-based protocol.

More generally, *any* interprocess communication protocol can be transformed into an equivalent "network-transparent" version based on the exchange of serialized messages; the point of designing for transparency up front is to make the serialization more efficient by preserving the original, higher-level representation, e.g. rendering commands rather than raw video,

Bingo! And this is exactly where you introduce multitude of bugs and inconsistencies. It's trivial to implement Windows-console or Wayland protocol: it's very simple, and very robust API. When you add high-level primitives you add complexity which leads to problems. For example if you offload text drawing to the server then you lose the ability to match your pre-rendered picture and your drawn-on-screen text (because you must use exact type of antialiasing in both cases). And the more complexity you add to your protocol the bugger is the outcome.

and by providing for high latency and being conservative of bandwidth, both of which tend to be useful properties in the local case anyway.

Nope. GPUs can very efficiently blend buffers. There are no need to bother with all these optimization unless your program requires them. Developer can decide if they want to create perfect rendering of the font (remember this article which showed example in which each line has a 1/10th pixel shift, so that, in the run of 30 lines it gradually (gradually!) accumulates 3 extra pixels?)…, or go with fast and loose implementation.