State of network transparency & a possible approach

[Manuel Stoeckl]

Hello all,


1.) I'd like to inquire about the state of network transparency for
Wayland; has there been any notable work since the 
Wayland-over-Wire patches and krh's 'remote' branch?

https://lists.freedesktop.org/archives/wayland-devel/2016-February/026933.html
https://cgit.freedesktop.org/~krh/weston/commit/?h=remote&id=7adffe7be46f4cb31c27066332356e4a19b609d5

I recently found an older, similar proposal to the below:

https://lists.freedesktop.org/archives/wayland-devel/2010-November/000037.html


2.) My current favorite plan of action to make network-transparency
feasible without significant breaking changes to libwayland, compositors,
and toolkits, and hopefully without cementing the details too early:

* Develop a network-transport protocol to communicate buffer changes.
  (In the worst case, changes can be serialized into a large number of
  Wayland protocol messages.)

* Develop a pair of applications that act as a server&client, and
  forward Wayland protocol messages between computers, but also scan
  the message stream for indications that a shared memory buffer 
  was modified, and inject new network-transport protocol packets
  to simulate the shared memory updates.

In the long run, the pair of forwarding programs could be absorbed by the
compositor and/or toolkit, eventually making the network-transport protocol
a first-class alternative to shared memory/passing file descriptors.

This approach is somewhat work intensive, as many protocols would require
interception, i.e, wl_shm, wl_drm, wl_data_source, wl_keyboard,
wl_data_offer, xdg_shell, and a number of the more recent protocols (i.e,
wlr_data_control, wlr_gamma_control.)

[Note; the above I plan to expand and use as a Google-Summer-Of-Code
proposal, but given sufficient free time, may implement anyway. Having
network transparency/shared nothing clients is a one of the main areas
where Wayland is not yet near parity with X :-(]

Any advice would be welcome.