phase in varlink and (optionally) gradually/eventually phase out D-Bus?

[jokeyrhyme]

systemd is phasing out D-Bus in favour of varlink for performance reasons: https://varlink.org/

and there's a discussion about following this over in xdg-desktop-portal: flatpak/xdg-desktop-portal#1449

is there interest/scope for doing this in AccessKit?

[DataTriny]

Hi @jokeyrhyme, interesting proposition.

The AT-SPI protocol relies heavily on providers emitting events and assistive technologies setting up match rules to filter out these signals. Varlink does not support broadcasting a message, as far as I know. Providers would have to keep track of interested clients. Note that AT-SPI itself supports providers spawning their own private bus and do peer-to-peer communications with clients, but it seem to be phased out and we haven't implemented it yet in AccessKit as it significantly increase the complexity of the provider side.

FYI the Rust library to use would likely be zlink, coming straight from the author of the D-Bus library we currently use.

AccessKit is only one piece of one side of the protocol, have you started the discussion with other actors?

• the atspi crate we use to talk to the registry
• the registry itself, the client library used by ATs and the provider side used by GTK and others

[jokeyrhyme]

true, varlink is different enough in paradigm (no central bus) that it's not quite a 1:1 mapping with D-Bus, and it might be different enough that the performance/modernity wins aren't worth the effort/complexity

The AT-SPI protocol relies heavily on providers emitting events and assistive technologies setting up match rules to filter out these signals.

varlink does not offer events, exactly, but it does support a single method call ( https://varlink.org/Method-Call ) that results in multiple responses over time, so this could be a viable mechanism similar to HTTP long-polling and other subscription-style APIs elsewhere

Providers would have to keep track of interested clients.

yes, with D-Bus, the bus keeps track of interested parties, but with a varlink approach there is no central bus so this functionality would likely need to be lifted into the providers

varlink should generally be faster and more efficient than D-Bus in a use case with exactly 1 provider and 1 consumer

but with assistive technologies, there could be 100s of providers and 10s of consumers (just a guess, maybe i'm way off?), so there's probably a threshold beyond which the number of simultaneously-active providers and consumers does work most quickly/efficiently with a central bus paradigm; this is something that probably needs more exploration

i'm hoping (if this pans out and there's sufficient interest) that we'd land on a small number of pub/sub-over-varlink implementation libraries that are adopted by providers, rather than every provider having duplicate all of this effort

Note that AT-SPI itself supports providers spawning their own private bus and do peer-to-peer communications with clients

this is quite promising, perhaps (after discussing with upstream AT-SPI) this is where optional varlink support could be introduced

AccessKit is only one piece of one side of the protocol, have you started the discussion with other actors?

i have not, so thank you very much for the pointers

i think i'll put this discussion on their radar, try to better understand/estimate the typical scale of consumer-to-provider connections, and from there try to put together some synthetic benchmarks to explore the potential benefits

[DataTriny]

I am honestly not convinced that replacing D-Bus by varlink would solve the performance issues of AT-SPI, not without significant architectural changes that is.

I have started working on AT-SPI3, inspired by the Newton protocol prototype. As much as I prefer evolution over revolution, I think switching to varlink would only increase the complexity of the provider side. Except that providers are by far the largest group compared to assistive technology implementors, yet they usually are the hardest to convince when it comes to emitting accessibility trees. So I think the future should make the provider side as simple as possible, asking for a semantical representation of the content and not much more technically. Produce a tree and push it somewhere.

With that being said, feel free to discuss this with the rest of the ecosystem. It would be interesting to have a proof-of-concept to gather some numbers.

For now I'll convert this issue to a discussion, as it is not actionable yet.

Thank you!