[Xcb] GSoC: final C code mapping for <switch>

Jamey Sharp jamey at minilop.net
Thu Jun 17 09:35:35 PDT 2010

I have three somewhat conflicting goals:

- I would like to have the value-params in the descriptions re-written
  using switch. The protocol descriptions should be as descriptive as
  possible, and this new tag clearly expresses the meaning of the
  protocol better.

- I think you're right to want to provide a more type-safe, structured
  API here. People who want to custom-assemble requests can use either
  xcb_send_request or socket handoff.

- Existing APIs for XCB protocol stubs should be preserved, but XCB's
  API shouldn't depend on how something is expressed in the XML.

I think together these mean that I want both of your proposed approaches
implemented in the code generator. :-/ By default, switch tags should be
generated using the structured type approach, but for extensions we've
already published, they should be generated like value-params currently

However, to get started, you could implement only the new style API for
switch, and don't touch existing XML descriptions. Then switching the
value-params over to switch is a separate project.

Does anyone feel strongly that we should use the void* style interface
for these switch tags? That would certainly side-step the above problem.

On Thu, Jun 17, 2010 at 6:45 AM, Christoph Reimann <chrr at arcor.de> wrote:
> (Just for the record: For the moment, I have decided on changing the
> serialization code - it is now done elementwise, see previous post on
> the list - simply because it's simpler and one could change it later
> (if necessary for performance reasons) without touching the API. )

By all means, do whatever is easiest while figuring out how to implement
these extensions--but I'd appreciate it if you'd put the generated
serialization code back the way it was when you're done.


More information about the Xcb mailing list