Re: experimental proposal

On Wed, Nov 12, 2003 at 05:37:32PM +0100, Egbert Eich wrote:
>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.

I've given it a lot of thought (and you were at the meeting when
I discussed it in January), and I believe that the apparent
complications can be handled within Xlib, and without causing
problems for legacy clients.  But all of this is why I titled this
message "experimental proposal."  To my knowledge this approach
has not been investigated, and I believe that it should be.  Patching
up problems with ad hoc extensions is not a scalable solution, IMO.

>Presently X.org is doing standardization for X. 

X.org appears to be doing a good job of maintaining the existing
standard.

>Have you addressed this issue there? 

I'm addressing the issue here, in an open forum.  The "standardisation"
mantra should not stand in the way of progress, development, and
extensions to the core standards.

David
-- 
David Dawes
developer/release engineer                      The XFree86 Project
www.XFree86.org/~dawes