[g-a-devel] Overview of DBus ATSPI design

[Rob Taylor <rob taylor codethink co uk>]

First off, I'd like to wish everyone a happy new year!

In preparation for the accessibility conf call tomorrow, here's an
overview of how we currently see DBus-ATSPI coming together:

== Quick DBus overview ==

DBus is really very different to CORBA. DBus is a message passing system
with a defined wire protocol. It is commonly used with a central bus
daemon that routes messages to protocol and allows discovery.

There are no defined language mappings, how a message appears is
language binding and possibly application dependant.

In D-Bus all messages are passed asynchronously but there is the concept
of a 'signal' which is a message that does not expect a reply.

== API and IPC separation ==

In current AT-SPI the IPC is effectively defined in terms of a
programmatic API. As we've seen in our profiling of current AT-SPI
usage, this results in very heavy IPC usage (for what is really not a
huge amount of actual data).

We propose that the design of the IPC mechanism should be focussed on
efficiency and simplicity, and API design should be implemented on top
of the IPC (per language and possibly per toolkit). Note that at the
moment almost everyone uses a wrapper around the generated ORBit
bindings already. One option is to have a common gobject based library
for use by ATs that can be bound into python or java.

By having this separation, we can have caching logic below the API and
optimise for minimal context switches.

Standardisation of API would be per language and per toolkit.

My feeling is that it's probably not possible to make everyone use a
common gobject based library to talk to the wire protocol, hence the
protocol should be well-described to allow alternative implementations
and should be forward-compatible.

== Process Architecture ==

(see attached png)

In the current system, all IPC is direct between processes, and there is
the registry daemon that deals with passing events and monitoring X
events and sending DeviceEventListener events.

The D-Bus session bus already acts as a central process for passing
messages and signals. In this respect it is well suited to acting as a
replacement for the registry daemon. The D-Bus session bus also has
advanced filtering mechanisms for deciding what signals a process wishes
to receive. Messages can be filtered by object path, interface, and even
message body. This could allow AT-SPI clients to register to receive
certain events from particular applications, and cut down on IPC traffic.

A process will still be required to monitor and forward device events to
the message bus. The D-Bus bus daemon could be modified to perform this
task, but it is just as easy to use a separate process. The use of a
separate process will mean the D-Bus session bus can be used. This is
already present in all distributions using D-Bus, making acceptance easier.

== Events and Signals ==

AT-SPI uses the EventListener and DeviceEventListener interfaces to
notify AT processes of application and device events. As events are
passed as method calls, they are delivered synchronously. Despite this
AT processes all seem to queue the messages to process later,
effectively making event notification asynchronous.

We propose that events should be asynchronous at the IPC level, using
the DBus 'signal' message type and routing.

In an asynchronous message passing system there is always the
possibility of a producer-consumer rate mismatch. Given that most AT's
have already subverted the existing synchronous event system to be
asynchronous in order to avoid deadlocks and other issues, it seems that
asynchronous message passing will be fine, and such mismat In a
producer-consumer rate mismatch case with DBus signals, the signal
messages will either queue in the bus daemon or in the receiving process.

== Reference Counting ==

We propose that there should be no implicit cross-process reference
counting in the IPC design.

The interesting case where reference counting is useful is when reading
large documents. Ideas are appreciated for how to approach this. One
possibility maybe a separate 'interface' in the IPC mechanism for
navigating within large documents which may be only partially laid-out.

Thanks,
Rob

-- 
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk