Ideas for X improvement.

[Glynn Clements]

David Jackson wrote:

> > The main thing to bear in mind is the client-server model. If you want
> > to migrate a connection to a different X server, you either have to
> > ensure that the new X server will behave exactly like the old one, or
> > make the client adjust to the change. The former is somewhere between
> > ridiculously difficult and completely impossible, while the latter
> > requires significantly changing the protocol, libraries, toolkits, and
> > applications.
> 
> The client wouldnt have to be moved between servers at all, it could be the
> same proxy server, the proxy server could then open up connections to actual
> X servers and forward things to the real X servers. The proxy would massage
> and rework data as necessary to trick the X client and hide the fact it is
> being displayed to many X servers and also keep the X servers in the dark
> about what is really going on as well.

This is the first option, "ensure that the new X server will behave
exactly like the old one".

> This requires no protocol changes and
> no changes to the clients or servers. There are already two or more
> codebases that this has already been done on, one is something called Xmux,
> the other was something called Xshare or something, and I am aware of a
> possible third that was called XTV. None are actively developed at this
> time.

XMX, Xmux, XTV and SharedX are discussed in "A Survey of X Protocol
Multiplexors". The only reference I can find to Xshare is a brief
description from its author on a page which hasn't been updated since
2001. I'm sure there have been more recent attempts, but none of those
seem to have been any more successful.

The main reason why these projects never go anywhere is that it's
difficult if not impossible to make them work once you stray beyond
the core features of the core X11 protocol, and the simplest
applications.

If you're only dealing with the core protocol, it's not too hard to
reasonably approximate the capabilities of one server on all of the
others. Having said that, all of the programs described in the above
paper had some problems even with the core protocol.

But this falls down when you try to handle something like OpenGL,
where the client queries the capabilities of the server and adjusts
its behaviour accordingly. It's simple enough for a client to use a
feature if it's available and avoid it if it isn't. It's a different
matter for a proxy/mux/etc to try to forward a connection from a
client which is using a feature to a server which doesn't have it (or
which has a more limited implementation).

It also starts to fall down when you move beyond a single, isolated
application to something which integrates with a complex desktop
environment. E.g. if client A communicates with client B, do you proxy
client B as well, and have each instance of client A communicate with
the matching instance of client B, or just have the "primary" instance
of client A communicate with a single instance of client B?

Of the four programs in the paper, only Xmux got a "strong pass" for
supporting cut and paste.

-- 
Glynn Clements <glynn at gclements.plus.com>