Hasn't somebody reimplemented X11 in JavaScript/canvas/websockets yet?
There was an X11 server for Lisp Machines! Not sure who wrote it, but it was probably written inside or at least nearby the X Consortium, and I remember Robert Scheifler used it regularly.
"For example the TI Explorer Lisp Machine came with an X11 server written in Lisp. On my Symbolics Lisp Machine I used the usual MIT X11 server written in C - this was possible because the Symbolics Lisp machine had a C compiler." -lispm
John Steinhart wrote XTool, a nice snappy reimplementation of X11 on top of SunView! ;)
>XTool was very small and
fast compared to the X sample server because I wrote the server from scratch.
I think that I'm the only person to write an X server outside of the X
Consortium. One of the things that I learned by doing it was that the X
Consortium folks were wrong when they said that the documentation was the
standard, not the sample server. There were significant differences between
the two.
>The only really worthwhile thing about X was the distributed extension
registration mechanism. All of the input, graphics and other crap
should be moved to extension #1. That way, it won't be mandatory in
conforming implementations once that stuff was obsolete. As you probably
know, that's where we are today; nobody uses that stuff but it's like the
corner of an Intel chip that implements the original instruction set. As
an aside, I upset many when working on OpenDoc for Apple and saying the
same thing there.
>The atom/property mechanism allows clients to allocate memory in the server
that can never be freed. Some way to free memory needs to be added.
>The bit encodings should be part of a separate language binding, not part
of the functional description.
>Had he done some real design work and looked at what others were doing he might
have realized that at its core, X was a distributed database system in which
operations on some of the databases have visual side-effects. I forget the
exact number, but X includes around 20 different databases: atoms, properties,
contexts, selections, keymaps, etc. each with their own set of API calls. As
a result, the X API is wide and shallow like the Mac, and full of interesting
race conditions to boot. The whole thing could have been done with less than
a dozen API calls.