AT-SPI on D-Bus Wiki (archival)

AT-SPI on D-Bus Wiki (archival)

Note: This is an archived snapshot of the Open Accessibility Workgroup's AT-SPI on D-Bus wiki page. The information contained here is historical, and should be considered out-of-date. The current version of the AT-SPI on D-Bus wiki page can be located at:

<a href=“http://a11y.org/d-bus” class=“external free” title=“http://a11y.org/d-bus” rel=“nofollow”>http://a11y.org/d-bus</a>

Original Introduction

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

1 AT-SPI on D-Bus Wiki (archival)

Note to page contributors

Small factual errors or ambiguities should simply be updated with an improved wording.
For open issues, it can be helpful to add your name to comments. Such discussions should be replaced with an updated summary of the point once a conclusion has been reached to help readability.
Please add a date wherever the information is subject to possible change in the future.
Please update outdated content.

Background facts

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)
- Qt contains an accessibility framework that is bridged to the native protocol of the platform (e.g. MSAA, Mac OS X Accessibility). This framework has been extended to contain everything needed for AT-SPI support. (This is similar to what Mozilla did with nsiAccessible, in order to support ATK).
- KDE is implementing AT-SPI support via Qt Accessibility, since KDE widgets are subclasses of Qt widgets and inherit Qt Accessibility support.
The current AT-SPI implementation contains some dependencies that impede its adoption in the KDE desktop and for KDE-based assistive technologies. (September 2006)
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.
- AT-SPI was originally designed for, and is currently implemented by the GNOME project using CORBA, an object-based IPC/RPC technology. CORBA is very portable but somewhat heavier weight than D-Bus. A number of feature gaps exist between D-Bus and CORBA.
- Qt 4.2 will contain D-Bus bindings. KDE 4 will use D-Bus extensively.

Evaluation of D-Bus and CORBA

Performance Comparison

information last reviewed and updated 24 July 2008 by Mike Gorse

In late 2007, Rob Taylor and Mark Doffman of Codethink conducted an investigation to study the feasibility of porting AT-SPI to DBus and evaluate performance.
- D-Bus has not been speed optimised yet, so all performance tests are premature.
- D-Bus developers have offered to optimise the D-Bus code for AT-SPI once we have created a performance test that fits the real-world use of AT-SPI. [1]
- The performance of CORBA is much slower if a different ORB is used, i.e. testing ORBit2 only is insufficient for evaluating a technology that intends to work with different ORBs. That said, the common ORBit2 ORB is currently shipped by the majority of Linux/Unix desktop distros, i.e. all distros which ship Gnome including those where Gnome is not the default desktop.
  - The various CORBA bindings are believed to be roughly equivalent in performance across languages. However there is a large advantage between ORBit2 and other CORBA ORBs since ORBit2 makes use of a sockets-based backend for local connections. The performance advantage thus gained is about an order of magnitude, based on benchmarks performed a couple of years ago with AT-SPI using ORBit2 in both local-sockets-mode and IIOP-over-ip-mode. The latter mode is the standard inter-ORB transport mode for most ORBs.
- D-Bus will be used for all KDE4 IPC, which will be an extreme stress test for D-Bus and makes quick stability and performance improvements likely.
- TODO: Is there a difference between the various D-Bus bindings with wrt. performance?
A pre-alpha version of a Qt-atk bridge showed extreme performance problems related to main loop issues (see below).
TODO: How do the various suggested bridging strategies influence performance?

Future Extensibility

Supporting additional scripting languages
- pyorbit allows Python scripts to use CORBA.
  - LSR, Orca, Dogtail and LDTP make use of this.
- D-Bus would also allow bash scripts or any other scripting language.
  - An example would be a simple script that tells X.Org to move the virtual screen to a new position when the focus changes.
    - Depending on the level of focus monitoring, one would be implementing screen reader functionality which is not trivial. Not a valid example.
- bash scripts are not equivalent to python scripts.
It would be good to extend AT-SPI to allow accessible remote access to applications. This would also make it possible to run applications as another user (sudo).
- The feature is expected in GNOME 2.17.See bugzilla #163132
- CORBA has network support built-in.
- D-Bus supports direct application-to-application communication via network and in sudo cases.
  - It is also planned to make the D-Bus desktop bus usable remotely.

Common Obstacles for Both CORBA and D-Bus

The current AT-SPI implementation assumes that a GNOME desktop is used. (September 2006)
- The Statement On Desktop Accessibility Development described the aim to “eliminate dependencies on any particular desktop”.
  - The GNOME team suggested at a later date that this goal could be satisfied by a reimplementation of the AT-SPI core code (instead of removing dependencies of the current implementation) [2].
    - I would distinguish dependency on a particular technology such as CORBA or even a library like ORBit2 from a “dependency on a particular desktop”. Since the underlying CORBA technology and protocol is publicly available standard (administered by the Object Management Group [OMG], and multiple free implementations are available, it would not seem to be an inherently unacceptable dependency. That said, I agree that moving to a technology that is already shared by the two desktops would be desirable. – Bill
  - The GNOME team has offered to remove some of the dependencies of the current implementation if this would make it more useful to the KDE team.
- TODO: We do not have a complete dependency list of the current AT-SPI implementation.
  - Probably we should distinguish the dependencies here by category - for instance the interface dependencies of the IDL, the ldd output from the various libraries installed by at-spi (with some explanation of what role each library plays), and also some analysis of which dependencies are likely to be spurious or incidental, versus those which are “hard” dependencies which would be difficult to remove. – Bill
  - IDL dependencies: AT-SPI IDL currently requires Bonobo_Unknown.idl, and uses three (fairly simple) methods from it. TODO: list them and link to Bonobo_Unknown, explaining what this means in practice.
  - Protocol dependencies: The current AT-SPI ABI depends on CORBA (any conformant ORB can be used).
  - libraries installed by at-spi:
    - libspi.so (primarily used by atk-bridge, which exports ATK interfaces via AT-SPI). TODO: list them
    - libcspi.so (simple 'sugar coating' for AT-SPI C clients, to reduce the ugliness of using the official OMG C CORBA bindings directly). TODO: list them
    - libatk-bridge.so (the actual atk-bridge implementation, which links to libspi.so).
  - TODO: Dependencies of the existing AT-SPI Registry implementation.
- Bonobo-activation is currently used for accessibility bootstrapping. An Xatom will be used as a replacement in Gnome 2.17, and could be used both for CORBA and for D-Bus.
  - The Xatom patches are already available in the GNOME bugzilla (at-spi-registryd, gnome-session, gdm)
  - Using Xatom for IOR [Interoperable Object Reference] rendezvous solves the multi-user (sudo) and multi-host accessibility issues (see above).
  - Where X is not available (e.g. embedded devices), the D-Bus activation mechanism could be used instead.
- Gconf and GNOME specific environment variables are used for accessibility bootstrapping.
  - There seems to be consensus that this could be replaced with a freedesktop.org (xdg) setting.
API compatibility: How can we keep the needed changes in assistive technologies small?
- Most existing language bindings for AT-SPI are CORBA-specific
  - TODO: Which parts of the APIs exactly are ORBit2 specific or CORBA specific?
  - For Python bindings, the CORBA specific part is much smaller.
- D-Bus bindings usually hide such implementation specific details.
- The use of cspi as a long-term compatibility layer is discouraged by its author.
- If we decide against a quick to migration to D-Bus, then we need to define a new abstraction layer for AT clients to guarantee a stable API long-term. Otherwise the migration headaches will be even greater in the future if more assistive technologies are coded to ORBit2-specific bindings.
If we decide to allow the use D-Bus and CORBA at the same time, then how will the two registries interoperate?
- One possible solution is to have a registry that speaks both D-Bus and CORBA.
- Another possible solution is to make sure that KDE and Qt applications speak both CORBA and D-Bus until enough assistive technologies speak D-Bus, and that the existing assistive technologies continue to speak CORBA until all atk is ported to D-Bus.
  - The two registries would then need to cooperate on input events. XEvIE 1.1 permits only one “master” controller.
Unfamiliar technology:
- Some of the accessibility developers lack D-Bus knowledge (but there are developers in all of the KDE, GNOME, Linux, BSD and freedesktop.org communities who would be able to help).
- The KDE developer community lacks CORBA knowledge, which is an obstacle for implementing the bridges. The few KDE developers with CORBA knowledge claim to have had bad experiences with CORBA during KDE 1.x times, but the GNOME team still has a lot of CORBA experience and could be asked for help.

Obstacles for Migrating AT-SPI Onto D-Bus

The quality of the Python/glib bindings is currently lacking. (TODO: details) (September 2006)
- The Python bindings are currently being rewritten.
- The existing Python bindings block when making a call to a non-existent object (during introspection. There is a workaround for this).
- The existing Python bindings do not create an org.freedesktop.DBus.Introspectable interface on an application's top-level object, making discovery of accessible objects problematic.
A central component is the Registry daemon so a new D-Bus implementation will be required (see above).
Object lifetime is an issue. D-Bus does not impose or offer any object lifetime support, but some parts of AT-SPI require it.
- We can probably assume that most AT-SPI objects are owned by the applications and destroyed when the application widgets are destroyed. But with that assumption, there are one or two AT-SPI objects that are problematic. For example, StateSet objects can be created by any part of the system (clients or applications). A workaround may be passing the StateSet object by value, but this solution is uncertain.
- Implementing object reference counting on top of D-Bus may be a performance problem.
Need to standardize on object references. A D-Bus object reference is usually an object path (Example “/org/freedesktop/accessibility/TheWidget”), but to fully specify an object reference, one must also know the bus name (service), and possibly the interface where the object lives.
AT dependencies on AT-SPI:
- Orca, LSR, Accerciser, AT-Poke, GOK, Dasher, Gnome-Mag, Dogtail, LDTP.
Application dependencies on AT-SPI:
- ATK/GAIL, Java Access Bridge, UNO/OpenOffice, XUL/Firefox, Eclipse, Workplace.

Obstacles for Using the Existing CORBA Implementation in KDE

According to the GNOME roadmap, Bonobo is going to be phased out in favour of D-BUS (http://live.gnome.org/RoadMap)
A few API incompatible changes to the current AT-SPI implementation are necessary anyway if we want to replace the current bootstrapping code with a less GNOME-dependent solution (see above) (September 2006)
An attempt to write a Qt-atk bridge failed because of several reasons:
- Dependencies - Getting AT-SPI up&running involves a lot of libraries and set-up.
  - Not feasible for embedded devices where every byte is important.
  - Quick inhouse check revealed that even modern distributions either get it wrong or simply don't offer AT-SPI support.
- Mainloop integration issues. (TODO: How did OpenOffice solve this?)
  - DONE: At the Linux Foundation Summit (June 2007) Lars from Trolltech reported that the glib mainloop issue in Qt was resolved.
  - OpenOffice had none of these issues: Michael Meeks did the work, and it took a week at most.
  - Michael offered help multiple times, by both private and public mail to the Trolltech guys doing glib mainloop integration: no response.
  - TODO: add substantive issues Trolltech encountered
  - TODO: be responsive wrt. discussing such things
  - TODO: lets address the root issue here, and get a shared cross-desktop event loop - it's key to lots of integration problems [ as becomes apparent here ]
    - TODO: Are the glib developers willing to split out the main loop from the rest of the library? Previous attempts to achieve this failed.
KDE-based AT clients would need to use an ORB either directly or via wrappers, but no stable CORB is known to run on all of KDE's target platforms. * omniORB: The list of [[http://www.omniorb-support.com/omniwiki/FrequentlyAskedQuestions
supported and ported platforms]] mentions a big number of unsupported ports and says that porting to BSD would be easy (but not yet done).
```
    *  KDE developers lack CORBA knowledge, so they are in a bad position to do this porting work.
    *  TODO: Are there any other obstacles for using omniORB in KDE?
  *  ORBit2 is quite mature, but no longer actively maintained.
    *  In Michael's words: "Conversely - there are ~no live / motivated / extant ORBit2 maintainers / developers around, and for better/worse the wave-of-the-future technology is D-BUS as of now." [[http://lists.freedesktop.org/archives/dbus/2006-July/005214.html|[3]]]
    *  TODO: What is the state of the C++ bindings for ORBit2?
    *  The [[http://www.gnome.org/projects/ORBit2/documentation.html|ORBit2 documentation]] focusses on technologies not relevant for the AT-SPI case (mainly GNOME and Bonobo). The general ORBit2 introduction contains sentences such as "Caveat: I don't know either". C++ documentation seems to be missing (apart from a link to the OMG spec).
  *  No other technology uses CORBA and GNOME is making great progress migrating away from it. Running an ORB just for accessibility is redundant if all desktops use D-BUS for communication.
    *  KDE removed CORBA for KDE 2.0 and replaced the technology with KParts and DCOP. This gave KDE applications interoperability not seen on any other Unix desktop.
```
===== Possible Migration Szenarios ===== ==== Szenario 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. Pros: * Ideal code sharing and interoperability. * No GNOME dependencies for KDE, even short-term. * Forward-looking. * Compatibility with embedded environment. * KDE accessibility aids can be written with simple shell scripts. * A single IPC is used for KDE/GNOME interoperability everywhere. * Smallest amount of required code long-term. Cons: * Big amount of required code short-term. * Possibly a very long lead time, with an untested infrastructure. * There could be delays in adoption by OpenOffice and Mozilla. * D-Bus is in an early development stage, so performance problems can be expected short-to-medium term. * KDE applications are not accessible with GNOME assistive technologies until those are ported. * KDE assistive technologies don't work with Gtk applications, OpenOffice and Mozilla until those are ported.
==== Szenario 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. Pros: * No GNOME dependencies for KDE, even short-term. * Forward-looking. * Compatibility with embedded environment. * KDE accessibility aids can be written with simple shell scripts. * KDE applications are accessible with GNOME assistive technologies short-term. * The authors of GNOME assistive technology could wait until the D-Bus version has stabilised. Cons: * An untested infrastructure used for KDE Accessibility. * KDE assistive technologies don't work with Gtk applications, OpenOffice and Mozilla until/unless AT-SPI migrates to a compatible D-Bus protocol. * Two different IPCs are used for AT-SPI at the same time. * Two different IPCs are used for KDE/GNOME interoperability (CORBA for accessibility, D-Bus for other things). * Either the AT-SPI registry must speak both, or two registries will need to cooperate.
==== Szenario 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. Pros: * Full interoperability achieved quickly. * The proven infrastructure is used until the D-Bus alternative is ready. * KDE and Qt application APIs remain “native”. * GNOME libraries are only loaded if available and required for accessibility. Cons: * More new code required than with approaches A or B, but less than with D. * QAccessible must either be bridged twice, or be bridged to ATK. * Some code for KDE assistive technologies needs to be written twice (for instance, the higher-level API client bindings). * No compatibility with embedded environment. * Short-to-medium term, KDE Accessibility requires GNOME libraries at runtime. * Short-to-medium term, KDE Accessibility requires two different ORBs at the same time. (Note: this need may be avoided if ORBit2 mainloop issues can be solved and the ORBit2 C bindings are sufficiently complete, in which case KDE can use ORBit2 short-to-medium term. It should be possible for the KDE AT client bindings to be ORB-agnostic).
Two different IPCs are used over the long term.
KDE assistive technologies cannot be deployed on some of KDE's target platforms unless we find an ORB that runs on all these platforms and has a suitable API for KDE to use.

Szenario 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.

Pros:

The proven infrastructure continues to be used.
No GNOME dependencies for KDE, even short-term.
Forward-looking.
Compatibility with embedded environment.
KDE accessibility aids can be written with simple shell scripts.
A single IPC is used in KDE everywhere.

Cons:

Biggest amount of required code (both short-term and long-term).
A lot of work before full interoperability is achieved.
Implementing a shared registry for D-Bus and AT-SPI is likely more work than writing a new registry for D-Bus.
QAccessible must either be bridged twice, or be bridged to ATK.
Some code for KDE assistive technologies needs to be written twice (for instance, the higher-level API client bindings).
An untested infrastructure used for KDE Accessibility.
Two different IPCs are used for accessibility.

Current Work (Updated 24 July 2008)

Work is on-going by Mark Doffman of CodeThink and Mike Gorse of Novell. Mark has written some notes on some of the design changes in the DBus implementation of AT-SPI 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://git.codethink.co.uk/git/atspi-dbus.

Table of Contents