4 ms·

Proper/secure composability is designed not by exposing all internals, but by explicit APIs. For example, UNIX file descriptions and using them as stdin/stdout/

by dchest 9y ago

Proper/secure composability is designed not by exposing all internals, but by explicit APIs. For example, UNIX file descriptions and using them as stdin/stdout/stderr is a properly exposed API for reusable components, while the ability to plug into any function in the binary would not be.

wander_homer 9y ago
X11, i.e. some of its implementations, don't expose all internals, and clients don't just plug into any function in the binary. The X11 protocol and some of its extensions clearly define how clients can communicate with each other or the server. Wayland on the other hand does not. How and if clients can communicate with each other is considered out of the scope of the Wayland protocol, except a few exceptions (e.g. copy/paste) so it's up to the Wayland compositor. That's why there are already multiple different "APIs" to do screenshots on Wayland compositors, some more powerful some less, and not a single one is implemented by all major compositors - basically fragmentation hell. That's also why stuff like color pickers still don't work without tedious hacks (e.g. misusing some of the screenshot APIs).
badsectoracula 9y ago
It doesn't expose its internals, the equivalent to UNIX file descriptors in X is the XID (Window, Pixmap, etc). Much like you can give any process any file descriptor to work with, you can also give any process any XID to work with. And like you can combine the text output of processes by redirecting their stdio, you can combine the graphical output by combining their elements (it isn't exactly equivalent of course, partly due to increased complexity inherent in GUI applications but also due to little standardization and tools, but still several of elements in an X desktop - outside GNOME and KDE that implement their own functionality which ignore X - work like that).

by dchest 9y ago

wander_homer 9y ago

X11, i.e. some of its implementations, don't expose all internals, and clients don't just plug into any function in the binary. The X11 protocol and some of its extensions clearly define how clients can communicate with each other or the server. Wayland on the other hand does not. How and if clients can communicate with each other is considered out of the scope of the Wayland protocol, except a few exceptions (e.g. copy/paste) so it's up to the Wayland compositor. That's why there are already multiple different "APIs" to do screenshots on Wayland compositors, some more powerful some less, and not a single one is implemented by all major compositors - basically fragmentation hell. That's also why stuff like color pickers still don't work without tedious hacks (e.g. misusing some of the screenshot APIs).

badsectoracula 9y ago

It doesn't expose its internals, the equivalent to UNIX file descriptors in X is the XID (Window, Pixmap, etc). Much like you can give any process any file descriptor to work with, you can also give any process any XID to work with. And like you can combine the text output of processes by redirecting their stdio, you can combine the graphical output by combining their elements (it isn't exactly equivalent of course, partly due to increased complexity inherent in GUI applications but also due to little standardization and tools, but still several of elements in an X desktop - outside GNOME and KDE that implement their own functionality which ignore X - work like that).