API feedback for an alternate libwayland implementation tailored for ffi bindings

[Victor Berger]

Hi Drew,

1 juillet 2019 21:08 "Drew DeVault" <sir at cmpwn.com> a écrit:

> Hey Victor! I want to quickly thank you for all of your hard work
> allowing Wayland to flourish in the Rust ecosystem, along with the rest
> of the community that supports you.

Thanks!

> Big +1 to more implementations of the Wayland protocol. wayland-rs is a
> great example of this. However, if this discussion leads to "we should
> replace libwayland upstream with something like this", hard NACK from
> me. Such a move would shrink the pool of contributors, deeply affect
> libwayland's portability (consider for example that I, personally, work
> with Wayland on RISC-V, which is not supported by Rust), and
> dramatically increase complexity and churn for questionable gains.

I never imagined to actually replace libwayland with wayland-rs, but I understand how my original message may have felt like this. Sorry for not being clear enough.

Coming from my history working on wayland-rs for 4 years now, there is something I can say for sure: libwayland's current API is *not* rust-friendly. As a result, wayland-rs contains a lot of boilerplate to fit it in a reasonable way into Rust's ownership model. I've at occasions seen on #wayland maintainers for other languages formulate similar complains.

Now, I've partially solved this issue for Rust by also making a full-rust implementation of the Wayland protocol in wayland-rs. But as soon as one needs to interact with something else (notably Mesa for OpenGL or Vulkan), this is an immediate no-go, as Mesa and the client app must use pointers coming from the same Wayland implementation.

This is why I came up with the idea of introducing an alternate API in libwayland, which would be more fundamental and more FFI-friendly. This would allow easier interop between the different languages and C libraries like Mesa or GTK.

I'm thus proposing a tentative design of such an API, and the possibility of implementing in wayland-rs as an experiment. If this is something that people are interested in and the experiment is successful, then I can imagine two paths forward (there might be more though, my imagination is limited):

- the newly designed API could be integrated into libwayland (but I expect this to require a significant refactor)
- I could reasonably provide an implementation of the ffi-taylored API on top of libwayland's API (after all I'm already doing something similar with wayland-rs)

This second path would mean (assuming the whole project succeeds) that users would then have 2 options:

- use the current C libwayland-client, and optionally a libwayland-client-ffi built on top of it
- use wayland-rs, which would directly implement libwayland-client-ffi, and provide a libwayland-client built on top of it

However I have no interest in developing a Rust implementation of libwayland's API if I cannot use it in a better way than the C implementation from Rust. So if this project is not welcome, I'll just stick to what I have currently: "You can use the Rust implementation only if you don't need Vulkan, openGL, or any interop with a Wayland-aware system library".

Victor