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

[Jamey Sharp]

Hi Alp!

The tone of your reply makes me think you're feeling defensive. Please
don't. :-) I'm not trying to fight with you, only to understand what
you're doing.

On Wed, Mar 15, 2006 at 08:58:49PM +0000, Alp Toker wrote:
> Jamey Sharp wrote:
> >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.

What is that special case and how does changing an attribute name in the
XML help? I would love to have the server dispatch code auto-generated
but I can't appreciate the simplification if I don't understand it. :-)

> 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.

You're more ambitious than I am. I expect the protocol headers to die
along with Xlib, and to change rarely regardless, so maintaining two
copies is not a big deal. It's also not hard to have special cases in
the header generator for GCONTEXT and the handful of other names that
aren't just first-letter-capitalized.

My goal is that the protocol documentation serve as documentation for
the language bindings as well, for any new development like XCB or XNB.
So although the all-caps name GCONTEXT is inconvenient for the special
backwards-compatibility case of generating Xlib-style protocol headers,
having to change the case for everything else is a cost I'm not excited
about paying.

> 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.

Good catch! xproto.xml hasn't gotten much review, and should definitely
get more. (I've been wanting to replace these with what's *really* in
the protocol description anyway, such as "do-not-propagate-mask", and
get the code generator to do the naming convention fixups for the target
language.)

> I'm working on identifying patterns to simplify bitmasks and valueparams 
> right now.

That's great! Can we help?

> 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.

I wouldn't say "unions aren't what the spec-writers had in mind:"

	A type of the form "T1 or ... or Tn" means the union of the
	indicated types.
	...
	DRAWABLE: WINDOW or PIXMAP

But I'll grant you that C unions aren't the only way to describe a union
of types -- they aren't even a very good way. Supertypes, which I recall
you've proposed, also act as type unions, as do Haskell's type classes.

Whatever way we describe these type unions in the XML needs to allow us
to generate code for C, object-oriented languages, Haskell, and anything
else that people want to use the X protocol from. For that reason I'd
appreciate hearing more from you as you consider solutions: whatever we
do here affects a lot of people.

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

Yes, although I wish you had come on board six months ago when we
weren't trying to get a release out in a few days. :-)

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20060316/8d0f9935/attachment.pgp