[Xcb] C code mapping of <switch>

[Jamey Sharp]

On Wed, Jun 9, 2010 at 8:49 AM, Peter Harris <pharris at opentext.com> wrote:
> If you were to generate the switch as a helper function that populated a
> buffer passed into it, and generated the request function such that it
> takes a void pointer where the switch is, then the function signature of
> the rest of the function wouldn't change sufficiently to break the API.
>
> IMO, one of the goals of XCB is to allow efficient usage, and push
> complexity into helpers and wrappers. If you *want* to hand-roll (and/or
> cache) the complex part of the request, you should be able to.
>
> But I don't have strong feelings on this. Would anybody else on the list
> like to comment?

You wrote what I would have liked to have written, but couldn't
express clearly. :-)

Since I have a habit of playing devil's advocate, though, I could
argue that socket handoff provides enough API to be as efficient as
you could possibly want, up to the limits of today's syscalls. If
somebody has a good idea for a more efficient way of buffering and
sending requests, or a more usable way, perhaps they should
demonstrate it as a layer on top of XCB first. Then we could discuss
whether to officially deprecate the current protocol stubs, or do
something else, as appropriate. Meanwhile, Christoph needn't worry too
much about efficiency--if we buy this argument.

When I've proposed more efficient interfaces for the protocol stubs,
Bart has argued before that XCB should primarily provide a usable,
idiomatic C API. So maybe his opinion will be that the new
switch-based stubs should do the packing themselves, similar to how
the wrappers in xcb_aux work. If I've guessed correctly, he might go
on to express a preference for changing the valueparam stubs to switch
stubs so they're more C-like, and--this is very much guessing--might
pooh-pooh my objection that such a change breaks API. I look forward
to Bart's response to find out how accurate I am. :-)

Jamey