[Xcb] xcb pre-release

[Barton C Massey]

Oh!  Yes, encoding the protocol properly and then making the
C binding generator punt is clearly the right answer for
now.  Thanks much for the suggestion!

	Bart

In message <87vdz3k6u8.fsf at ambire.localdomain> you wrote:
> () Barton C Massey <bart at cs.pdx.edu>
> () Thu, 17 Jul 2008 17:16:50 -0700
> 
>    The basic problem is that we provide no way of easily
>    constructing, on the user side, a packed list of strings of
>    known size and count to use in requests.  However, part of
>    the philosophy of XCB is that it won't repack data for the
>    application: the app is expected to pass parameters in a
>    format ready to put on the wire.  This is a feature for
>    performance-concerned apps that keep the data lying around
>    in the proper format, but it's not so much a feature for
>    figuring out what's going on.
> 
> Sounds good, at the C level.
> 
>    Thus, in a few cases such as SetFontPath, we currently just
>    punt and ask for a char* and a length.  This is clearly a
>    bug, but we haven't heard a better suggestion.  Probably the
>    best we can do is just provide the function everybody wants
>    in util/aux.  Better suggestions are gratefully accepted.
> 
> Thanks for the explanation.  I suggest you keep the C bindings of the
> protocol spec (and their specific performance-related assumptions,
> such as this case) separate from the encoding of the X Protocol in
> XML.  This way, the encodings can be more useful on their own apart
> from the C bindings (an original design goal, IIUC, and one that i
> fully support).
> 
> Practically, this means extending the patch to include the workaround
> plus explanation (such as the one written above) in the code (python,
> now?) that generates the C bindings, preserving continuity for users
> of the C bindings.
> 
> I realize this is more work and that people are itching to get a
> release out, so i won't object if such a combined patch is accepted
> later.  (It will take me some time to grok the C bindings generation
> code, anyway.)
> 
> thi