[Xcb] xcb and protocol versions
jkolb at brandeis.edu
Thu Feb 22 16:08:21 PST 2007
Peter Hutterer wrote:
> On 23/02/2007, at 05:48 , Jeremy A. Kolb wrote:
>> I am unsure how to handle the case where the client uses a
>> request from an older version of the extension that has now changed its
>> signature in a later version of xcb.
> don't change it. If you decide to fill existing padding fields with
> data, that is fine because the client won't access them. if you start
> adding bytes, you will most likely get the client out of sync. there's
> probably some stuff you can do with fake padding. say you have a request
> with a length field and a count variable. count gives you the number of
> bytes after the 32 standard. you could change length but not count,
> resulting in fake padding bytes being added at the end. for newer
> versions, you can then stuff data in there. not sure it's wise to go
> there though.
> If you want to extend a request, you have to have version negotiation
> and send back exactly what the client wants, depending on the version
> the client is running.
> Multi-Pointer X Server
Sorry I wasn't clear. I'm not writing an extension, I'm implementing
protocol version support in xcb.
An example of my concern is:
We have an extension Ext at version 1.0 and we have a request named func
that sends a CARD16 down the wire.
XCB would generate the following functions;
Now if we have version 1.1 and let's say we still have request func but
it adds a CARD8 or something then we would have the function:
xcb_ext_func(..., CARD16, CARD8)
Will we ever run into a case like this or are people prohibited from
doing things like this?
More information about the xorg