[Xcb] [Bug 29743] New: dynamic protocol bindings

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29743

           Summary: dynamic protocol bindings
           Product: XCB
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Protocol
        AssignedTo: xcb at lists.freedesktop.org
        ReportedBy: hp at pobox.com
         QAContact: xcb at lists.freedesktop.org


It would be useful to have fast runtime access to something like the XML
protocol descriptions (but converted to a binary format), similar to
gobject-introspection. This would allow language bindings to dynamically
generate wrappers on the fly. It would also allow things like xtrace or more
one-off debug hacks to use the protocol descriptions.

Even the C binding would have the option to go dynamic. The protocol bindings
are not tiny:
$ size /usr/lib/libxcb-glx.so
   text       data        bss        dec        hex    filename
  64447       2616          8      67071      105ff    /usr/lib/libxcb-glx.so

In theory, each request could be nothing but a call to a dynamic invoker like
this:

xcb_send_request_dynamic(connection, flags, request_description, ...);

where "..." would be the args currently passed to the wrapper, and
"request_description" would be the binary equivalent of the xml description.

Some notes on this:

* it would be nice to add the request name to the current
xcb_protocol_request_t for debugging purposes. supporting lookup of request
description given major and minor opcode, for example, would be super useful.

const xcb_request_description_t* xcb_describe_request(int major, int minor)

printf("got request %s\n", xcb_describe_request(major, minor)->name);

* ideally request_description would avoid any references to other symbols. I
think e.g. the address of the extension id in xcb_protocol_request_t creates
relocations. Qt's moc compiler generates descriptions as one huge string, for
example, so there's only one symbol and it points to the read-only data
section.

* in principle the xcb protocol wrapper libraries could just be the requests
description blob in the library itself, plus headers with macros expanding to
xcb_send_request_dynamic. for compat reasons you'd have to make the
request-sending APIs functions instead, but they could just be functions that
invoke xcb_send_request_dynamic() and nothing else. If the libraries contained
only one read-only const symbol (the request description) then they would have
notably less overhead than they do now. That's not back compatible, but even
reducing each function to be just an invoke of xcb_send_request_dynamic() could
result in some nice shrinkage.

* a dynamic setup would perhaps be slightly slower, but the reduced size
probably matters more in the real world, and it ought to be pretty fast

* the dynamic setup makes non-C language bindings fixed-size, instead of a
multiple of the number of requests the binding supports. (same principle as
gobject-introspection)

* http://ometer.com/parallel.html could be used to deprecate the static C
bindings

* whatever happens with the C bindings, exporting the "introspection data" at
runtime instead of in effectively static-only (due to efficiency issues) XML
files would be very useful for debug tools and language bindings.

Does this sound reasonable or does it conflict with some XCB goals?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.