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

Activity

1. jokeyrhyme

   changed the title [-]phase in varlink and gradually/eventually phase out D-Bus?[/-] [+]phase in varlink and (optionally) gradually/eventually phase out D-Bus?[/+] on Jan 5, 2026
2. DataTriny commented on Jan 7, 2026

   

   DataTriny

   on Jan 7, 2026

   Member

   More actions

   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
3. jokeyrhyme commented on Jan 7, 2026

   

   jokeyrhyme

   on Jan 7, 2026

   Author

   More actions

   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
4. DataTriny commented on Jan 7, 2026

   

   DataTriny

   on Jan 7, 2026

   Member

   More actions

   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!
5. AccessKit

   locked and limited conversation to collaborators on Jan 7, 2026
6. DataTriny

   converted this issue into a discussion #672 on Jan 7, 2026