[Xcb] xcb and protocol versions

[Jeremy Kolb]

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.
> 
> Cheers,
>   Peter
> 
> -- 
> Multi-Pointer X Server
> http://wearables.unisa.edu.au/mpx
> 

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;

xcb_ext_func(..., CARD16)

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?