[wizzwizz4]

> GNOME’s Wayland session is now stable and usable with Orca.

They did that via an out-of-band D-Bus protocol, rather than going full Wayland. I'm all for keeping D-Bus around for backwards-compatibility (lots of things use AT-SPI2, and I certainly don't want a repeat of the CORBA -> D-Bus migration), but Wayland's AT support should be first-class, not relegated to proprietary GNOME extensions.

Per Matt Campbell's article https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the..., this decision has something to with security:

> Assistive technologies or other accessibility clients currently connect to the compositor through a D-Bus protocol, defined in the Mutter repository linked above. By exposing this interface via D-Bus rather than Wayland, we make it easy to withhold this communication channel from sandboxed applications, which shouldn’t have this level of access.

[jauntywundrkind]

Excellent excellent call out. This feels very wrong direction, this using a side-band for accessibility!!! I had no idea.

It's surprising to me that security would prompt the push to D-Bus. Wayland's design with the compsitor as the message bus center was built to center security in the architecture, to make the compositor the arbiter of data flows. I'm struggling to picture what the issue was here with sandboxed applications.

[holowoodman]

Compositors are incompatible with one another and have totally different levels of functionality. Most compositors don't do any proper kind of security and permissions and just limit data flows in the most primitive and restrictive way possible. Using something with existing security but the possibility of cross-communication like DBUS is just easier here. Although I expect a lot of confused deputy type of exploits there...

[jauntywundrkind]

> Compositors are incompatible with one another and have totally different levels of functionality.

I see far more similar about compositors than different. They have freedom of implementation & do different things, but they offer to apps a very common set of protocols, and some of the newer edgier protocols have more varied adoption. But I see standards & growth & development forward as 'what Wayland is', not "incompatibility" (that's why Wayland proper is purely 100% protocols & not a bespoke impl) and "totally different" (???).

Finding formal concensus to make special stable has been hard. But there is a pleasantly large amount of overlap and interop, even if compositors end up implementing more than one flavor of say gamma control.

> Most compositors don't do any proper kind of security and permissions and just limit data flows in the most primitive and restrictive way possible.

When starting a composite yeah, you figure out who has input and send it there. You render the surface the apps give you. Dataflow is inherently quite unidirectional for a long time when beginning a desktop compositor.

But that doesn't feel true at all today. Most compositors support advanced screen sharing, virtual pointers, and other fairly advanced data-flow protocols, almost all built security in mind, requiring more advanced routing & permissioning, as is very visible with the screen share flows of most apps.

> Using something with existing security but the possibility of cross-communication like DBUS is just easier here.

Agreed, but you yourself in your very negative comment on Wayland in this topic seem quite opposed to second systems in broad basis (and pretty radically down on Wayland in general). I'd like to see the display system protocols able to better tackle talking about and managing what's on the screen, rather than building a second parallel system for saying and working with what's on the screen.

I also think there's a decently strong basis already there in the current protocols. There's a security context to start. https://wayland.app/protocols/security-context-v1 We see more advanced flows like XDG Foreign for apps to expose surfaces and mix them onto our own apps.

At-spi d-bus was already right there & done, and it felt easy to keep using it. It was mostly convenience I feel like, and the justification of security feels like a blunt hammer to deny exploration. https://gitlab.gnome.org/GNOME/at-spi2-core/

[tuna74]

Maybe it is actually better to do these accessibility operations over D-bus than over a Wayland protocol. Just because something existed in Xorg does not make it the best solution.

[wizzwizz4]

CORBA (or D-Bus) was needed in the X11 days, precisely because X11 didn't really provide a better solution. Wayland does. See https://wayland.freedesktop.org/docs/html/ch04.html#sect-Pro...:

> The Wayland protocol is an asynchronous object oriented protocol. All requests are method invocations on some object.

Anything D-Bus can do, Wayland can do. (Except systemd integration, but that says more about systemd than about Wayland.)