Not quite. The X server ran on the client only. The "mainframe" (usually a Unix server) had client programs that would connect to your X server, send it display commands, and receive pointer and keyboard events. The client-server relationship was reversed from the usual way, because the server was sitting in front of the user. The end-user computer was providing a service -- access to the user -- to the big machine in the server room.

We do use them, it is called browser nowadays.

I like this analogy... It's very true, and has a lot of local rendering which at the time of X terminals was a bit of a pipe dream. They could just locally render some things like fonts.

Sun also tried to get into this game early with the JavaStations. But they were ridiculously slow, so painful to use. In fact they kind of ruined Java for me. I was learning it at the time, and we got a JavaStation on loan from somewhere. Working on it just established this "Java = slow" feeling in my head and really put me off so much I went to do other things.

Of course this wasn't really deserved, and Java has gone on to become powerful (though I still consider its poor intra-version compatibility an issue). But I've never been able to quite shake that feeling.

I don’t know, web browsers today are almost too powerful to be called “virtual programmable HTTP terminals”...

Almost there, you login to the server and run application, that application connects to the X Server on your client:

    +----------------+     +----------------+
    | Client         +---->+ Server         |
    |                |     |                |
    | +-----------+  |     | +-----------+  |
    | |X Server   +<---------+Application|  |
    | +-----------+  |     | +-----------+  |
    |                |     |                |
    +----------------+     +----------------+

"X device" would be better name — as you connect to the server application draws on your X device.

In the linux world I work on, a very large percentage of the developers are frequently unknowingly running X via ssh tunnels. Its just to convenient to be able to run the graphical version of tools on the remote dev/test machine than to live all day long restricted only to the GUI tools on your local machine and a terminal session.

The one place that X could use some updating is all the sync method calls, that unlike RDP become quite slow if the network connection has any real latency.

> The one place that X could use some updating is all the sync method calls, that unlike RDP become quite slow if the network connection has any real latency.

I wouldn't say the one place, but it is a pain point.

(And actually, many of the supposedly synchronous things are not synchronous at the protocol level, but at the C library binding level -- xlib. Nowadays there's a much closer to the protocol binding: libxcb.)

Thanks!