Wayland - Beyond X (The H)

Posted Feb 15, 2012 23:16 UTC (Wed) by nybble41 (subscriber, #55106)
In reply to: Wayland - Beyond X (The H) by khim
Parent article: Wayland - Beyond X (The H)

> Not just for TUI. GUI, too. ... Most network-transparent protocols lead for the mess both in TUI and GUI case.

I'm not seeing that at all. Your examples all come from the legacy serial terminal and its escape codes, and do not apply to GUIs. Elsewhere you did state that "When you see garbage in your console and when you see overlapping text in your [remotely served] Firefox it's the exact same failure", but (a) I've never seen that kind of failure, and (b) even presuming it exists, it doesn't really seem like the same thing at all.

> If TUI suffers from the introduction of “effective network-transparency layer” ...

But it doesn't. TUI suffers from being forced to work through a protocol which was not "designed" so much as "evolved", in the very early stages of computer science, before we learned to design proper protocols, constantly merging features from similar-but-incompatible protocols and being extended and forked for various special cases. The implementation *is* the standard, and yet there is no single reference implementation. Given all of that, it's something of a wonder that it works at all.

I doubt a direct-access protocol would work as well--consider trying to write such a TUI when there is no standard memory layout, color/style encoding, character encoding, input API, etc. That interface is simpler only because it is standardized. If you ignored the issue of legacy compatibility, and simply defined what you want the terminal to do (perhaps based on the Windows terminal API), you can trivially provide a well-defined way to serialize those commands into a stream of messages which will achieve the same effect without any of the problems you've described.

> ... if we can not even handle simple case (TUI) then what hope is there for more complex case (GUI)? ... why don't you expect the similar effect on GUI?

Basically, because the GUI case (both for X11, and even more so for whatever remoting protocol is used with Wayland) is not nearly so encumbered by the need to remain compatible with legacy clients. There are actual independent standards involved. X11 has some legacy clients to deal with, but the original protocol was still much better defined than "serial communications with ANSI/VT100/xterm escape codes". The Wayland remoting protocol is in an even better position to adopt a rational design.

to post comments

Wayland - Beyond X (The H)

Posted Feb 16, 2012 1:10 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

>I'm not seeing that at all. Your examples all come from the legacy serial terminal and its escape codes, and do not apply to GUIs.

They do. The whole X-Windows uses exactly the same architecture - series of 'escape codes' over a serial line (Unix socket or TCP pipe). And the same argument apply - X works poorly both in remote AND in local cases.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 15:29 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> The whole X-Windows uses exactly the same architecture - series of 'escape codes' over a serial line (Unix socket or TCP pipe).

That is a gross oversimplification. Yes, they both use serial protocols. Most things do nowadays. However, X11 doesn't use "escape codes"; the protocol is designed around structured messages with clear boundaries. More importantly, each X client has its own state and an independent connection to the X server, so they can access the screen and input without conflict. The problem you described are an artifact of the particular set of protocols used for serial terminals, not serialized protocols in general.

> And the same argument apply - X works poorly both in remote AND in local cases.

To say it works "poorly" in either case is another exaggeration. For what it was originally designed for, it works just fine. Technology has moved on, of course, and the prevalence of client-side rendering means that we now have rather different requirements for efficient rendering than we used to. The core rendering protocol is mostly unused, clients tend to provide pre-rendered buffers, the addition of compositing support means an extra round-trip, etc. However, I don't believe I've _ever_ seen the kinds of problems in X which you've described for TUI applications.