[RFC] XI2 draft protocol specification (v 0.1)

[Jim Gettys]

Here are some substantive issues:

1) I wonder how we can extend XI2 to deal with multiuser displays (with
some sort of security between users), when we have enough experience to
work out the details.  Do we distinguish via the deviceid?  If so, is 16
bits of deviceid enough?  (allowing for 256 users of 256 devices, as a
possibility...).  Or is a separate user field for each device better? A
device might someday be as simple minded as a playing piece on a
chessboard (with sensors, for example).

2) if there are a lot of devices, coming and going possibly/probably
even in the same session, it isn't clear that notifying clients of their
(temporary) absence is desirable.  I think the spec should be written
allow a device to be absent and reappear without notification (within a
session); but a new device appearing in a session notify interested
clients.  With wireless devices, absence will occur with regularity...

The spec says: "Device IDs may get re-used when a device 
        is removed."; maybe better that the server somehow guarantee 
that clients be notified if the device ID is being reclaimed?

3) XIQueryDevices has limitations.

I worry in particular of N client toolkits getting notified of a new
device.  How do we limit notification traffic?  Should you be able to
limit XQueryDevices to list devices of a given user ID? (see above).

4) Extensibility of events.

I'm very concerned about how we can add new device types without having
to update the X server and client; the network effects of deployment get
to be a huge PITA.  We got stuck on fonts for > 15 years due to this
problem.

We have a number of ways forward I can see:
   o do what we're doing now.  But even with named AxesClasses,
ButtonClasses and DeviceClasses I'm worried.  Here's why: Interning
atoms require a round trip, and won't we end up with way too many types?
And do we really want to be a registry for such names?  Looking at the
USB specs, there are *tons* of devices and various types.  We thought
we'd avoid this in the early X11 design by the "predefined atoms" stuff,
but it didn't work out well in the end; it would have been better to
just use strings and send them everywhere in the protocol.  The registry
headache is not to be undertaken lightly.  Similarly, we're mostly out
of the keysym business by punting most of it to the Unicode consortium.
   o We can use the USB descriptor stuff and send the devices bytes to
the clients for arbitrary devices and leave it to the client to parse
the bytes.  This keeps us out of the registry and data definition
business; but it is ugly.  The USB stuff is decently documented.
   o we can say "it's not our problem" and adopt the /dev/input protocol
for transferring data; but as I've discovered looking into multitouch
devices, that just moves the problem to linux kernel land.  And
deployment will be limited to the rate of evolution of the Linux USB
driver and still requiring updating the X driver too. Not sure what
other platforms might think as well.
   o we could define a mapping between USB descriptors and XML events,
and send all this as XML.  This isn't entirely crazy. In fact, most
events end up as XML inside browsers anyway.  It is very extensible.
There are binary versions of XML if we wanted to go this way; though
care on design to avoid verbosity (and transmitting a data descriptor
first (or on device change) and just the data is very possible).

I'm not sure I like any of these options, to be honest.  But I think we
should talk them through.
                          - Jim


-- 
Jim Gettys <jg at freedesktop.org>