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 differ

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.