RFC: server-side XCB

[Christian Linhart]

On 12/21/14 01:27, Josh Triplett wrote:
> 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. 
This may have some challenges because request-handling
functions in the X-Server are often called through function pointers
and these function-pointers may be redirected by some X-extensions and DDXes.

So, changing the parameter list of request handlers has to be carefully considered.
It may open a can of worms.

For the fixed-size part of a request it is probably better to pass a pointer to
protocol-data with type of a struct that directly maps the protocol data
to struct-fields, such as the structs which are already generated by XCB.

This has better performance than passing each field separately as a parameter,
and leads to less cluttered parameter-lists.
Long parameter-lists can easily be a source of bugs
because we do not have named arguments in C.

For the var-sized part it may be useful to pass xcb-iterators or deserialized data
as an extra parameter to the protocol handlers.

> That same server code can
> then call an XCB reply-generation function, which will pack reply data
> onto the wire.  
Yes, agreed. I have proposed it the same way, with an example
in my proposal for "server-side XCB impl of requests, replys, events etc"
that I posted today.
> (Bonus if you can then trivially substitute a different
> transport/RPC layer, 
I think substituting presentation layers would usually be based
on a generator based on XCB protocol definitions.

In this case it will help if the function interface
can be easily mapped to any presentation layer.
Is that your point?

Even in that case, the XCB-structs for the fixed-size part
would work well because they are semantically equivalent
to having individual fields on the parameter list.

(To be exact, this is not about different transport-layers,
because X already has different transport layers such as
TCP, Unix-pipe, SHM, ...
This discussion here is about different presentation layers.
Currently we have only one presentation layer, and that's
the X-protocol. )

How relevant is having multiple presentation layers for X?
If it is not relevant we should not care about it,
so we can avoid all the headaches that come with
a presentation-layer agnostic design.
Not to mention performance...
> or write an X protocol proxy that passes through to
> another X server.)
An X-protocol proxy may work directly on the protocol using
a custom generator to generate code from XCB-protocol definitions.
(I have written such a thing for a commercial project.)

Of course, if a proxy has to do a lot of manually written stuff,
then functions could be better.

But, especially for a proxy it is probably better to use a struct
for the fixed size part instead of passing all fields individually,
because in many cases the proxy will only modify a few of the
fields and pass everything else unchanged.

>
> 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.
Hmmm.
The problem is that we have to stay compatible on the client side.
And we probably should use the same stuff on client and server side.

If you can make a proposal that ensures backwards compatibility
while making the XCB API easier to use, and having equal or better
performance, then this is worth considering, IMHO.

***

I propose to use libxcb as it is and only do minimal
adaptations to make it usable in the X-Server.
This has less risk and is less work.
But it may not be as elegant as the design you describe.

I suggest we do the simple and less-risk stuff now,
and think about more elegant XCB for long term.
Especially since XCB is already an area needing
improvement in quite a lot of places,
especially in the area of protocol coverage and correctness.

In any case the more elegant API design needs to be
carefully designed, so it'll probably take quite long
to be realized. ( and of course this will need lots of
implementation work... )

I also think that a design of a new XCB API should
only be started after all of the protocol is covered by XCB.
I had to introduce several new constructs to XCB-XML to be able
to support the XInput extension, and there may be more
such things to do for other extensions.

For designing a good next-generation XCB-API, you'll need to know
all the constructs that the protocol description language
will support. We don't know that yet.

So better wait with a new XCB-API until we have full
protocol coverage in XCB.

Chris


>
> - Josh Triplett
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel