Maybe try to make remote wayland actually happen, to see if there is something in the protocol/architecute that makes it harder than it should be.
This was attempted unsuccessfully for a GSoC: http://www.phoronix.com/scan.php?page=news_item&px=OTgxMQ
Remote display of wayland using wcap: http://lists.freedesktop.org/archives/wayland-devel/2012-June/004026.html
<nobled> question: if "values are represented in the host's
byte-order," and it's going to be possible to run
wayland remotely over a network, what happens if the
compositor has opposite endianness from a client?
<krh> nobled: which values?
<nobled> just quoting http://wayland.freedesktop.org/docs/html/sect-Protocol-Wire-Format.html
<krh> nobled: ah, we'll tunnel the wayland protocol in some kind
of container protocol
<krh> so we can have a endian/etc handshake at that level
<krh> and use one channel for the wayland protocol and other
channes for fd and buffer content
<krh> one such protocol could be spdy, actually
<nobled> well presumably fd passing is not going to be something
you can do over a network socket...
<nobled> so it's not a good idea to have a handshake or something
in wayland itself?
<krh> right, you need a proxy server that looks like a local
wayland server, which then talks spdy (for example) over
the internet to the remote server
<krh> that server will read from fd's in the protocol and turn
them into a spdy channel
<krh> nobled: I don't think so
Initial prototype here:
Not going to let this block 1.0 though, taking off blocker list.
Not really a core Wayland issue as such.