RFC: server-side XCB

[Josh Triplett]

[Resending this from the address that's actually subscribed.]

On Sat, Dec 20, 2014 at 12:27:08PM -0800, Jamey Sharp wrote:
> We've talked about doing the xserver equivalent of XCB for years--that is,
> auto-generating the protocol serialization and deserialization code from
> XCB's machine-readable descriptions of the X protocol and extensions.
> 
> Considering the recent CVEs in that code, I think it's time. So I want to
> collect folks' thoughts on what server-side XCB should look like.
> 
> At a high level, which code should we be generating? Off the top of my
> head, I'm thinking the dispatch tables and all the swap procedures, as a
> first target in order to get the codegen infrastructure merged and tested.
> Then it'd be nice to generate code that validates arguments and returns
> appropriate errors. Thoughts?

XCB's client code turns a function call with arguments into data on the
wire. I think the XCB server code should turn data on the wire into a
dispatched function call, with approximately the same arguments and
types as the original XCB client function. That same server code can
then call an XCB reply-generation function, which will pack reply data
onto the wire.  (Bonus if you can then trivially substitute a different
transport/RPC layer, or write an X protocol proxy that passes through to
another X server.)

We've talked several times about modifying XCB's client layer to make it
easier to construct requests more incrementally, particularly for
complex nested structs/arrays, to avoid having to hand-construct a
complex data structure before calling XCB. (APIs like protobuf-c might
provide some useful inspiration for incremental construction of nested
data structures.) I think the server has more calls that would require
such an incremental API, so designing that in from the start seems
preferable, rather than adding it after first constructing an
all-data-at-once API.

- Josh Triplett