I'm afraid I'm dreadfully confused by your comment.
"The typical answer I see is "you can send the same bits locally that you do over the wire", but nobody ever explains why that's even desirable for a network protocol."
Yes, you can use a network protocol to chat between local processes as well as between remote processes. Desirable? It's impossible to avoid...
"Transparent, distributed RPC was tried in the 90s and largely judged a failure."
True (ahem[1]), but irrelevant. X isn't a remote procedure call system.
"Not to mention that ever since the introduction of the MIT-SHM protocol, which is used by most everything to transfer image data, it hasn't even been true in practice for the last 20 years. Most modern enhancements to X11 have been about taking the X server out of the loop for as much as possible."
This is true; network speed hasn't kept up with graphics power and requirements for the most part, so processing has been pushed to the client. On the other hand, HTTP/HTML/JS/CSS can be seen as a poor-man's reimplementation of X (or more closely, of Plan 9 client-ui/server-processor protocols). And for the 20 years previous, clients were underpowered in comparison with a big honking machine you could log into remotely (or at least a dedicated machine that didn't have to bear the weight of a graphical interface).
"...even advocates of the principle usually use something like NX which is a network-designed fork of the protocol..."
I'm not sure what you mean be NX. The...
"NX technology, commonly known as NX, is a proprietary software application for remote access, desktop sharing, virtual desktop on Linux and file transfer between computers. It is developed by the Luxembourg-based company NoMachine which also lends its name to the software." (wikipedia)
which has nothing to do with X other than being descended from one of the low-bandwidth X extensions. (Not the low-bandwith X, and low-bandwith means dial-up. Plain ol' X was pretty chirpy on a SPARCstation with 10MB ethernet.)
"...multiple independent streams so we don't have reach head-of-line blocking with roundtrips..."
Welcome to the wonderful world of TCP.
"...and client-side rendering."
Once upon a time, there was a thing called a Sun Ray (https://en.wikipedia.org/wiki/Sun_Ray), basically a (non-3d) graphics card glued to an ethernet card, that was used as a thin client for a Sun server. I didn't see one until after I'd used an IBM X-terminal (a smallish pizzabox that ran the X server and pointed everything else at a bigger IBM box) for several years and the latter was much better than the former.
I'm saying that "a local protocol that can function as a networked protocol" isn't always an ideal design decision. We should consider designs that allow different local and remote protocols, and consider the tradeoffs in each space separately.
> Yes, you can use a network protocol to chat between local processes as well as between remote processes. Desirable? It's impossible to avoid...
Using a network protocol to chat between local processes comes with a lot of drawbacks. UNIX local sockets support features like datagrams and FD passing, and of course you can communicate resources in a shared namespace (e.g. a filesystem paths). So limiting yourself to the lowest common denominator of a TCP socket restrains the kinds of tools your protocol can make use of.
> X isn't a remote procedure call system.
It has requests, and it has replies. Xlib will block on a reply by default. That's the building blocks of a classic RPC system. It has all the messiness of distributed systems, but none of the innovations from the past 40 years. Error handling is particularly gnarly in Xlib; since all resources are global, another client can stomp on or delete your window behind your back. You can't be sure of anything before you try, and get an error back. In theory, you can make a lot of requests without blocking, but that's a super annoying process and isn't easy to do in practice; lots of information requires getting a reply back from the server.
> which has nothing to do with X other than being descended from one of the low-bandwidth X extensions
It has a lot to do with X11! It's championed as an example of the success of X11's "network transparency", but instead is very much a custom design suited for the network.
I don't think anyone strongly objects to the consensus that Xlib is a bad binding of the X protocol for these reasons. But libxcb has been usable for quite some time by now.
I keep reading what you write, and also was there (I used X10 at one point, and built the Athena platform from 9-track tape). I dunno...the whole screed strikes me as bizarre.
You say things like "Xlib will block" and "error handling is particularly gnarly in Xlib", when Xlib is only one possible implementation of the X protocol. There are other possibilities like XCB. I have no idea if it has the same issues as Xlib, but the inability to separate protocol from implementation speaks to a specific bias.
Further, you obsess over the use of the term "network transparency" like a previous generation used the term "commie", even cite up-thread "documentation" where the term isn't used. But no less that Jim Gettys used it to describe X11: https://static.usenix.org/event/usenix02/tech/freenix/full_p.... You might find it inappropriate, but it doesn't seem to be confounding vernacular to most other commenters.
I dunno...I think we've gone beyond butthurt because people didn't agree with you on the direction a project should go, to some obsession that has nothing to do with the technology.
"The typical answer I see is "you can send the same bits locally that you do over the wire", but nobody ever explains why that's even desirable for a network protocol."
Yes, you can use a network protocol to chat between local processes as well as between remote processes. Desirable? It's impossible to avoid...
"Transparent, distributed RPC was tried in the 90s and largely judged a failure."
True (ahem[1]), but irrelevant. X isn't a remote procedure call system.
"Not to mention that ever since the introduction of the MIT-SHM protocol, which is used by most everything to transfer image data, it hasn't even been true in practice for the last 20 years. Most modern enhancements to X11 have been about taking the X server out of the loop for as much as possible."
This is true; network speed hasn't kept up with graphics power and requirements for the most part, so processing has been pushed to the client. On the other hand, HTTP/HTML/JS/CSS can be seen as a poor-man's reimplementation of X (or more closely, of Plan 9 client-ui/server-processor protocols). And for the 20 years previous, clients were underpowered in comparison with a big honking machine you could log into remotely (or at least a dedicated machine that didn't have to bear the weight of a graphical interface).
"To make X11 usable over the network..."
X11 has been usable over the network since 1987 (and X < 11 before that) (https://en.wikipedia.org/wiki/X_Window_System#Origin_and_ear...).
"...even advocates of the principle usually use something like NX which is a network-designed fork of the protocol..."
I'm not sure what you mean be NX. The...
"NX technology, commonly known as NX, is a proprietary software application for remote access, desktop sharing, virtual desktop on Linux and file transfer between computers. It is developed by the Luxembourg-based company NoMachine which also lends its name to the software." (wikipedia)
which has nothing to do with X other than being descended from one of the low-bandwidth X extensions. (Not the low-bandwith X, and low-bandwith means dial-up. Plain ol' X was pretty chirpy on a SPARCstation with 10MB ethernet.)
"...multiple independent streams so we don't have reach head-of-line blocking with roundtrips..."
Welcome to the wonderful world of TCP.
"...and client-side rendering."
Once upon a time, there was a thing called a Sun Ray (https://en.wikipedia.org/wiki/Sun_Ray), basically a (non-3d) graphics card glued to an ethernet card, that was used as a thin client for a Sun server. I didn't see one until after I'd used an IBM X-terminal (a smallish pizzabox that ran the X server and pointed everything else at a bigger IBM box) for several years and the latter was much better than the former.
[1] Protobuffs, et al., notwithstanding.