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. (comment added
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
Note: The information in this section was last reviewed and updated on 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.
- 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 distrobutions, i.e. all distrabutions 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 regard to 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.
- 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. Consult GNOME bug
#163132 for more information.
- 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. (comment logged: 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).
- 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. comment by Bill Haneman
- 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
implementations.
- 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. (comment added by Bill
Hanemen, 2006)
- 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 themlibatk-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:
- Application dependencies on AT-SPI:
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;
- 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) (comment added
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:: Find and Document how OpenOffice solved 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 with regards to
discussing such things
- TODO:: let's 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 C++ ORB is known to
run on all of KDE's target platforms.
- omniORB: The list of 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 Meeks' 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.
(source: Michael Meeks, post to FreeDesktop.org's D-Bus discussion list)
- TODO:: What is the state of the C++
bindings for ORBit2?
- The 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 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
- 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.
Scenario A: 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.
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
- 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.
Scenario B: 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.
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
- 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.
Scenario C: 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.
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
- 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.
Scenario D: 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 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://git.codethink.co.uk/git/atspi-dbus.
Please report any problems encountered with this page or the resources to which it links
to: webmaster@a11y.org
Please report any factual
errors in this document by emailing accessibility-atspi@a11y.org,
a publicly archived emailing list.
