[Xcb] Re: Branch 'xspec' - xcb-proto

[Alp Toker]

Jamey Sharp wrote:
> On Wed, Mar 15, 2006 at 12:01:19PM -0500, Jeremy A. Kolb wrote:
>> onnoff is the name given in the headers,  Since we want to be true to the 
>> protocol shouldn't this name remain unchanged?
> 
> Yes. The XML files are supposed to be a representation of the wire
> protocol: if a particular binding, like XCB or XNB, needs different
> naming conventions etc. it's expected to provide them in its code
> generator.

The string "onoff" is never sent down the wire. A boolean value is sent, 
and that boolean value describes whether event notification is enabled. 
"enabled" seems to be an accurate description of the field while "onoff" 
looks like a mistake in the spec. I have a more complete justification 
in my previous message. If I'm missing the point here, would be quite 
willing to revert the change.

> 
> Alp, you're doing a lot of work to change things that I'm not sure
> should be changed: XML-XCB attribute names (opcode->number), type names
> (WINDOW->Window), and occasional field names (onoff->enabled). Remember
> that XCB needs to use the same files, so if you ever want to merge your
> changes you need to be talking to the rest of us. What's your plan here?

The opcode -> number change was made to remove the need for a special 
case in server code. I'm quite surprised that you don't appreciate the 
simplification for the C server binding generator. It's no great deal, 
but it makes life just a little bit easier at no extra cost. Again, 
would be quite happy to revert this if I've got things wrong.

As far as the naming changes go, the rationale is that you can easily go 
from GContext to GCONTEXT, but not the reverse. It seems that without 
the changes I've made in the xspec branch, replacing the protocol header 
files will be quite unintuitive. If you don't replace them, you're still 
left maintaining a minimum of two copies of the protocol for another 20 
years.

Perhaps for you this is less of an issue, but non-C language bindings 
can't depend on anything in /usr/include/X11

You'll find that other changes I've made actually _remove_ xlibisms that 
have crept into the XCB protocol spec and have replaced or am in the 
process of replacing them with the actual name from the protocol 
documentation.

For example, "DontPropagate" doesn't look good to me, but it starts to 
look even worse when you realise that it was actually meant to be 
"DoNotPropagateMask" all along. They got it right, then you got it wrong 
when you decided to copy-and-paste from xlib instead of working from the 
X11 protocol documentation.

I'm working on identifying patterns to simplify bitmasks and valueparams 
right now. Replacing the union element with something closer to the 
desired type model is on my todo list; any extension is free to create a 
new xid type that is also a Drawable, and unions, while they might be a 
handy way of representing that relation in C, are certainly not what the 
X11 protocol specs have in mind and don't seem to belong in a protocol 
description. It just doesn't click.

Isn't XCB a great opportunity to get these things right?