API feedback for an alternate libwayland implementation tailored for ffi bindings

Victor Berger victor.berger at m4x.org
Mon Jul 1 10:14:26 UTC 2019


Hi everyone,

A few weeks ago was discussed on IRC the idea or re-using my Rust implementation of the Wayland protocol [1] to build an alternate implementation of the libwayland C API. This is an idea I'm interested in, and apparently at least a few other persons are interested as well.

However, if I'm going to re-implement a libwayland with a C API, I'd be willing to adapt its API, to make it more friendly to FFI bindings (after all Rust remains the main language in which I interact with Wayland). Breaking backwards compatibility being naturally a nonstarter, my idea is to rather create a library exposing both the current C API and an alternate API, under a different namespace.

This alternate API would be specifically targeted at languages bindings, and not meant to be used directly by C applications. I have made a draft of such an API for client-side, with detailed comments about the guarantees it'd provide and how it should be used on this gist: [2].

The main design goal I followed with this draft is to be as friendly as possible to the other languages (guided by my experience of Rust) meaning:

- the caller language controls the lifetime of all objects (no pointer is implicitly freed behind your back)
- thread-safety guarantees are specified and explicited
- global state is not touched (returning error codes rather than accessing errno)
- ownership of allocations does not cross FFI boundary

It also specifies more precisely the semantics of message dispatching and exposes a choice for the FFI bindings to register dispatcher callbacks to the Wayland objects or to handle events as they come in an iterator-like fashion. This choice can be done per object, giving precise control to the language bindings of the way they handle message dispatching.

My focus would then be to implement this new API using Rust, and then add the necessary glue code to implement the current C API on top of it, then exposing the whole thing as a drop-in alternative to libwayland-client.so. I leave handling the server-side API for a later time.

I'd like to have your feedback on this tentative API before I try to implement it, especially from other language bindings maintainers. I may very well have missed some important question when designing it.

[1]: https://github.com/Smithay/wayland-rs
[2]: https://gist.github.com/vberger/417729269d15cf11c8098aff683d5c56



More information about the wayland-devel mailing list