AT-SPI on D-Bus (archival snapshot)

Open Accessibility (A11y)

Note: This is an historical snapshot of the original Open Accessibility Workgroup's AT-SPI on D-Bus Wiki. The current version of the AT-SPI on D-Bus wiki can be found at:

Purpose of This Document

This page serves as a summary of the various technical issues related to the D-Bus migration of AT-SPI. It serves as a summary of the current state of discussions (facts, agreements, open questions).

  1. Note to page contributors
  2. Background facts
  3. Evaluation of D-Bus and CORBA
  4. Possible Migration Scenarios
  5. Current Work (Updated 24 July 2008)

Note to Page Contributors

Background Facts

  1. Trolltech is implementing AT-SPI support for Qt, both on the Unix desktop and on embedded devices like mobile phones. This support is not ABI compatible with the existing AT-SPI implementation, which does not run on embedded devices. (comment added September 2006)
  2. The current AT-SPI implementation contains some dependencies that impede its adoption in the KDE desktop and for KDE-based assistive technologies. (comment added September 2006)
  3. Trolltech and KDE wish to move AT-SPI onto D-Bus, which is a toolkit-neutral IPC protocol. It was designed for GNOME/KDE interoperability and is used in the Linux kernel. It is extremely portable.

Evaluation of D-Bus and CORBA

Performance Comparison

Note: The information in this section was last reviewed and updated on 24 July 2008 by Mike Gorse

Future Extensibility

Common Obstacles for Both CORBA and D-Bus

Obstacles for Migrating AT-SPI Onto D-Bus

Obstacles for Using the Existing CORBA Implementation in KDE

Possible Migration Scenarios

Scenario A: Short-Term D-Bus Move

We quickly agree on a D-Bus strategy. Trolltech implements AT-SPI support via D-Bus. KDE4 assistive technologies are coded to D-Bus. In parallel with this effort, the Python-based assistive technologies are modified to support both CORBA and D-Bus. GNOME, OpenOffice and Mozilla migrate to D-Bus at some future date.

Scenario A: Pros

Scenario A: Cons

Scenario B: Medium-Term D-Bus Move

We quickly agree on a D-Bus strategy. Trolltech implements AT-SPI support both via ATK and via D-Bus, allowing KDE applications to be fully accessible both with D-Bus and with CORBA. KDE4 assistive technologies are coded to D-Bus. GNOME, OpenOffice and Mozilla need a longer time to migrate.

Scenario B: Pros

Scenario B: Cons

Scenario C: Long-Term D-Bus Move

We decide to postpone the D-Bus migration until everyone is ready to move. In the meantime, KDE-based assistive technologies use CORBA bindings, which can link to either OmniORB or ORBit2 at runtime; the CORBA bindings are hidden behind a higher-level API. Embedded devices use a D-Bus-based AT-SPI fork, which might or might not be compatible with what we agree on later for the desktop.

Scenario C: Pros

Scenario C: Cons

Scenario D: Parallel Use of D-Bus and CORBA

We implement a registry that speaks both D-Bus and CORBA, allowing applications and assistive technologies to choose.

Scenario D: Pros

Scenario D: Cons

Current Work (Updated 24 July 2008)

Work is on-going by Mark Doffman of CodeThink and Mike Gorse of Novell. Mark has written some detailed notes on some of the design changes in the DBus implementation of AT-SPI currently being worked on. In summary, remote reference counting is not being done for performance reasons, and some of the data associated with objects will be cached by the AT-SPI bindings to avoid the need to make round-trip calls to the application for all queries. The code is at git://

Please report any problems encountered with this page or the resources to which it links to:
Please report any factual errors in this document by emailing, a publicly archived emailing list.

Valid XHTML 1.0 Strict (check for yourself!)   Web-Content Accessibility Guidelines, Level Triple-A Compliant   Hand-Constructed Using W3C Validated Cascading Style Sheets!