X11 bashing

[Byron Rakitzis]

In article <1991Apr17.194141.17315 at wlbr.imsd.contel.com> mh at roger.imsd.contel.com (Mike Hoegeman) writes:
>In article <14820 at helios.TAMU.EDU> byron at archone.tamu.edu (Byron Rakitzis) writes:
>>I think the successor to X will somehow allow dynamic reconfiguration
>>of the server (via, say, an interpreted language) so that the network/context
>>switch bottleneck can be reduced.

>Gee... This sounds a lot like NeWS does'nt it? 

NeWS actually has some good ideas in it; I would not dispose of it in
a single statement like that.

However, I don't think the answer to X is NeWS. But it's clear that if you
nail your window protocol in stone (as X does) and that protocol operates
at a very low level (as X's does) then the bottleneck for high performance
graphics will be at the network/protocol level.

If you do not allow dynamic reconfiguration of the window system, then every
time you need to add a feature to the window system, you have to recompile
the window code. This may or may not be an acceptable solution for you. I
don't think it is.

The interpreted language I have in mind is not PostScript. The language
that is interpreted (or compiled on the fly for performance) should
be "safe", i.e., it should not be possible for any single client to
starve the resources of the window system, or to cause the window system
to crash. If you do not use a "safe" language, then either 1) you will
have to put up with the above 2 faults, or 2) you will have to write
a window "kernel" that manages client processes in a protected environment
with separate address spaces etc. The latter solution implies some fancy
hardware, and I would like to see this window system written for all sorts
of hardware, e.g., X terminals, or as user processes under Unix.
--
To reveal art and conceal the artist	| Byron Rakitzis, Texas A&M.
is art's aim.  -- Oscar Wilde.		| byron at archone.tamu.edu