[RFC] XI2 draft protocol specification (v 0.1)

[Daniel Stone]

Hi,
I was going to reply to the original, but Peter's reply says pretty much
everything I wanted to say.

On Mon, Feb 23, 2009 at 10:29:42AM +1000, Peter Hutterer wrote:
> On Sun, Feb 22, 2009 at 12:28:23PM -0500, Jim Gettys wrote:
> > 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).
> 
> I don't think we should have the notion of a "user" in the protocol. X is (or
> should be) an abstraction layer for input devices, the notion of a user (in
> regards to input devices) is too context-sensitive to build into the protocol.
> 
> Get the DE to label the devices through properties, and then apps to listen to
> these properties correctly, similar to EMWH. The big advantage of this is that
> a property-based protocol is easier to test and easier to modify than the wire
> protocol.

Or just do it through XACE.  I mean, if you're after security, then
surely you'd rather it was properly enforced through our existing
security framework rather than hoping people respect the convention.

> > 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.
> 
> In regards to the atom worries:

Not to mention that we can also make XInternAtoms do multiple atoms at
a time with Fixes.

> >    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).
> 
> XML is merely a container format. It doesn't solve our actual problem - what
> information to send to the client.

Preach it, brother!

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20090223/b693d0a6/attachment.pgp>