Making libwayland more FFI-friendly
As maintainer of wayland-rs, I've been working with the API of libwayland from Rust a lot, and I've encountered a few aspects in which I believe some additions to the API could be made to make libwayland-client more friendly to FFI bindings. Overall, it boils down to allowing more low-level access, which would solely be used by said bindings (as already exist, like the set_disptacher
functions).
I'm opening this issue to discuss these potential additions, and would be willing to implement them if they are accepted on principle.
-
wl_proxy_create_versioned
: This would be a trivial addition to the API of libwayland-client, I don't expect this one to be controversial. libwayland-client already provideswl_proxy_create
, which allows a client program to manually create a proxy before sending it to the server viawl_proxy_marshal_array
, rather than relying on its automatic creation viawl_proxy_marshal_array_constructor
. Doing so can be useful for language bindings on several fronts: for example the proxy can be assigned to an event queue before even being sent to the server, ensuring any potential race is completely avoided. Overall, allowing the binding to be in charge of the creation of proxies (just like server-side) would be more practical, from my experience. However, the absence ofwl_proxy_create_versioned
makes it impossible to do such a thing for objects created from the registry, rendering the whole idea void. -
Side-stepping the internal dispatch mechanism. I expect this one to be more complex and controversial. This idea would be, on an event-queue basis client side, to add a function that would just return the next available message to dispatch, instead of calling all callbacks for all available messages. This would shift the message-processing into a pull-based model, in which the FFI bindings take on the responsibility of forwarding the message to the logic responsible for handling it.
- When using this API, the role of libwayland would be limited to the serialization & deserialization of the messages, as well as maintaining the internal state of the protocol. The FFI bindings would be free to implement any message dispatching strategy as fits best the target language.
- It, of course, comes with a caveat: the event-queue on which this method is called should be entirely controlled by the FFI binding and only used in this way, as otherwise messages may be lost (and similarly for server-side). This is however in line with the best-practices of sharing a Wayland connection between different libraries: each one is expected to create its own event queue to process the events of its objects. We may consider implementing this as two different kind of event queues, to make it easier to catch errors.
- I'm not sure how feasible it would be server-side, given the absence of event-queues. Though the need for FFI-friendliness server-side is less pressing than client-side, as sharing pointers to Wayland objects between different libraries is less pervasive than in client apps.