Re: experimental proposal

David Dawes writes:
 > I've been thinking about the following for a while, and even ran it by
 > the core team at a meeting in Linux World in January of this year (to
 > a rather cool reception, but they can be a conservative bunch :-).
 > 
 > I don't think anyone argues with the fact that the X11 protocol has some
 > deficiencies that should be corrected.  The main area of disagreement
 > seems to be in how best to correct them.
 > 
 > My plan is to do some experiments to see if a so-far unused mechanism
 > that the X11 protocol creators provided would provide a better way of
 > achieving than adding on a bunch of ad-hoc extensions or creating
 > unnecessary incompatibilities.  The mechanism I'm referring to is the
 > protocol minor version number.  One of the first things that happens
 > when a client connects to a server is a protocol revision version
 > handshake.  The first part of this proposal is to see how effective this
 > mechanism is in practice.
 > 
 > If it does prove effective, then the next step would be to define a set
 > of protocol fixes/enhancements that would become version 11.1 of the X
 > protocol, and implement them in our Xlib and X server in such a way that
 > they are only used when both client and server indicate that they can
 > speak version 11.1 of the protocol.  On the client side of things, it
 > should be possible to handle this negotiation completely within Xlib.
 > 
 > If this mechanism proves effective, then it would open the way to
 > more frequent protocol revision updates as problems/limitations
 > arise rather than waiting over a decade to deal with them.
 > 
 > At this point, I'm interested in whether anyone has any feedback to
 > offer on this idea.
 > 
 > Once the 4.4 release is out of the way, I'm planning follow up on
 > step one.
 > 

Adding 'fixes' to the X protocol by bumping the minor number may be
the way to go for things that are not optional. Extensions probably
should be reserved to optional features. The set of proposed changes 
that currently are subsumed under the term "XFixes" may be candidates.

However introducing these things into minor updates of the core
protocol definitely calls for standardization. Incompatible minor
versions of the core protocol are much worse than incompatible
extensions which at least can be kept apart by their names.

Maybe the reason why these things are presently handled in an 
extension is that these things are still experimental and one
whishes to explore possible side effects and better way of handling
things before those are introduced in the core protocol.

Furthermore one needs to consider that the connection to the
Xserver is usually handled by Xlib. Legacy clients that are
not prepared to handle the new minor revision of the core protocol
may get confused if the shared Xlib is exchanged underneath them.
This of course could be fixed by advertising a higher minor revision
only if the application explicitely asks for it (thru a new Xlib
call).
Things may even become more complicated as most Xlib calls are
be dealt with by toolkits which would also handle the version
negotiation. However clients (or libs they link against) may 
directly interact with Xlib but still assume that Xlib speaks
the original protocol. 
However a careful design may help to spare us from surprises.

Presently X.org is doing standardization for X. 
Have you addressed this issue there? 

Egbert.