[RFC] XI2 draft protocol specification (v 0.1)
daniel at fooishbar.org
Sun Feb 22 18:19:17 PST 2009
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
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!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: Digital signature
More information about the xorg