How about making the standard client library's API the interface, and have it hide whatever the system is actually using?

A long time ago when I looked at designing a X11 replacement, that was my approach. AFAIK, only special X utilities used anything but Xlib anyway. And later I think this is what early revisions of Canonical's Mir did.

▲

mort96 7 hours ago | parent | next [-]

So .. still using sockets, but not documenting how the messages on the socket look? Why?

▲

to11mtm 6 hours ago | parent [-]

If I had to guess, because then at least -hypothetically- easier to optimize for the 'local' case (depending on implementation, at least from my understanding of the POSIX/*nix paradigm, bending and breaking a bunch of rules possibly) by dropping in a different implementation.

▲

mort96 6 hours ago | parent [-]

Optimise how? There already is only the local case in Wayland, pixel data is shared using shared memory which only works locally. Only small communication messages are sent via the socket. And the Wayland protocol also uses native endianness because, again, it only cares about the local case. It even sends file descriptors over the socket.

So what would you do differently in an alternative client library?

	▲	to11mtm 6 hours ago \| parent [-]
		> So what would you do differently in an alternative client library? I should have better disclaimed my comment.... to be clear I don't know much about the graphics subject, I probably should have prefaced it with, "I don't know anything about Wayland but as someone totally naieve on the subject but assuming someone else's assumption". At least to me, even if it breaks the X11 model (Which is a shame, that was fun to play with back in the day) if they're doing it the way they are I'm guessing Chesterton's fence will come into play at one point or another.

▲

dmytrish 6 hours ago | parent | prev [-]

That's what wayland-client does.