A Gov Application Developer's Perspective - X Windows future?

All:

I develop systems for the U.S. federal government. While the fed is one of the largest users of
X Windows based GUI tools, there are a number of problems with the future of X Windows in
this arena. I don't know the details of the Keith Packard controversy, but I can tell you that his
many papers on X Windows performance are definitive. I am sorry to see this apparent rift develop.
We need to be solving a lot of problems that have to do with performance, and some
that have to do with reliability.

Some of the issues for the future of X Windows in the federal world include:

1) Performance/comms - X Windows uses huge numbers of very small packets. This is a recipe for
disaster in many future network environments, including the Internet.  LBX doesn't help much -
as pointed out by Keith. Don't know the solution, but I do see the need for a better way to
distribute graphics workload across client and server.

2) Performance/Windows implementations - The current Cygwin port of XWin32 is incredibly slow. Our benchmarks
show that it runs something like 10x slower than commercial X servers for Windows. Like it or not, Windows
is the platform of the future for analysts' desktops. We need the highest possible quality of graphics
service on these machines.

A start might be an X Server written from the ground up to use native Windows GDI and DirectX
functionality. Adequate OpenGL support has been around for Windows for some time.
When are we going to have similar support for X?

3) Reliability/Web enablement - Yes, I am very familiar with Broadway, X Web, LBX, etc. None of this
works in practice as well as what we need.   One problem is that web browsers
make lousy window managers. Another problem is that web deployers generally want their applications
to work on ANY CLIENT with ANY BROWSER. Until such time as X Windows is universally available
as a built-in or plug-in for all major browsers and all versions of those browsers, browser compatibility
is an issue. Java has a similar problem, mainly due to Microsoft's obstinacy, but we are getting to
the point that Java works fairly well with IE, Netscape and Mozilla.  X Web has not yet achieved
much general acceptance.

I am also familiar with the major commercial replacements for X protocol: Citrix, Tarantella, GoGlobal.
All largely solve the browser compatibility problem. There are some performance improvements here
and some MAJOR PERFORMANCE HITS with these technologies. For example, Tarantella can run
a factor of 10x to 100x slower than native X Windows technology.  For highly dynamic user interfaces,
this is not an acceptable solution.

4) Performance/distributed processing - Ideally, you want to be able to divide up the workload intelligently between
application host and user's machine (app/client or X client/server).  X Windows has made a stab at this.
Sometimes X works very well at shifting the burden to the client (X server). However, in many practical
applications we need to be able to shift more of the burden to the application (X client).
Xvfb is useful but it is only a start.

Some people say X is obsolete because the world is going away from client-server technology.
This is not entirely true, IMHO. Multi-tier architectures still use client-server functionality for
many functions. However, what is needed is a way to intelligently support "thin clients".
In the graphics world, this means keep the large volumes of data on the server yet still
supporting acceleration on the client (X server).
You need to do that rendering on the server (X client) that makes sense to do there (rendering that
requires large amounts of data and little user interaction) and to do that rendering on the
client (X server) that makes sense to do there (rendering that requires small amounts of data and that
requires a greater degree of user interaction). Neither Web X nor Java nor Citrix et al nor SVG
nor RWT nor SWT nor anything extant today has got it exactly right!

Please keep in mind that a game has different requirements than a typical analysis application.
For the former, all the data is typically located on the user's machine (client/X server).
For the latter, you really cannot ship terabytes of data to thousands of users' PCs. This
problem demands an intelligent client vs server division of labor!  There can be similarities.
Maybe you want to ship blocks of data to the client (X server) for caching . Absolutely this
is appropriate in many circumstances. In other cases, it just won't work.

Imagine a virtual reality game in which the system simulates an entire planet. Individual
clients may cache parts of their local virtual environments. No client is big enough to
store or process the whole thing. This is a game analogy for the fed problem, except that
the feds prefer large centralized servers to a truly peer-to-peer distributed system.
Again, what is needed is a GUI framework that automates the intelligent division of labor.
between client and server.

5) Reliability/Anachronisms - IMHO, the world would be better off if "color map" were to disappear from the
community's vocabulary. Color maps and problems with X Windows fonts continue to plague
deployers of X Windows applications.  This is ridiculous.

6) Performance/Hardware acceleration - Absolutely any acceptable solution needs to fully support hardware
acceleration. An ideal solution would support both offscreen hardware acceleration on the application
side (X client) and onscreen hardware acceleration on the client side (X server). Some of this
capability exists today, but it needs to work seamlessly and reliably on essentially all
platforms before we can declare victory.

7) Development/maintenance costs - The numerous standard X APIs and extensions are so
complex that development and maintenance costs are excessive. IMHO, X needs a serious
house cleaning. Instead of demanding backwards compatibility, the old stuff should be
gradually obsoleted and deleted. Face it, it is becoming tough to find X books anymore
in the computer bookstores because the commercial and government worlds are both
abandoning X for simpler APIs that are more easily applicable to the Web.

Thanks for reading my comments-

Jim Schatzman
Northrop Grumman Mission Systems