[Xcb] xcb pre-release

Thien-Thi Nguyen ttn at gnuvola.org
Fri Jul 18 00:08:15 PDT 2008


() 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


More information about the Xcb mailing list