IMPORTANT: This article is being preserved for historical purposes and likely no longer reflects the state of AT-SPI over D-Bus.

ATSPI D-Bus Design

This page is used to collaborate on the detailed design of AT-SPI over D-Bus as it evolves.

Vocabulary

CORBA

Accessible Object - The Bonobo object, accessible remotely that implements one or more of the "Accessible" interfaces.

D-Bus

Accessible Object - The proxy on the AT side containing a D-Bus object path on which one or more "Accessible" interfaces are supported.

Object References

AT-SPI currently exports its interfaces using Bonobo objects. These objects proxy a real element within the application, which is most usually an ATK object. Bonobo objects are remotely reference counted. The first major change in design, when moving to D-Bus is that remote reference counting should not be implemented.

AT-SPI should act on proxy objects that only hold weak references to the real application elements (ATK objects). In this scenario, the proxy will be notified when the ATK object disappears, and should return sensible values when accessed in such a state.

D-Bus registration

ATK objects must register themselves with the D-Bus AT-SPI library, this in turn must provide a D-Bus object reference for them to be accessed remotely. There needs to be a mapping from the D-Bus object path to the ATK object, if it still exists. This mapping needs to be updated as ATK objects are created / deleted.

One option is to provide a transparent mapping where the Object reference uniquely defines a place in the tree of ATK objects, so that they can be looked up directly. The object path would be "/org/freedesktop/atspi/accessibles/1/2/3/45" This has issues as the ATK objects sometimes move around, and the AT side proxy objects would than have to have their Object paths changed.

Another is to keep a mapping between ATK Object pointers and a unique object path. The object path may look something like "/org/freedesktop/atspi/accessibles/AF12BB12". Lookups will have to take place in both directions, so it may be best to maintain two hash tables of the data.

A plauisble API for this functionality:

The module may be called object_mapper.

ObjectMapper* object_mapper_new(char* base_object_path, MapperMessageCallback* callback, DBusConnection* connection)
void object_mapper_delete(ObjectMapper* mapper)

int object_mapper_register(ObjectMapper* mapper, void* object)
void object_mapper_deregister(ObjectMapper* mapper, void* object)

char* object_mapper_get_path(ObjectMapper* mapper, void* object)
void* object_mapper_get_object(ObjectMapper* mapper, char* path)

Here the purpose of the object mapper is to register server side objects and make them available remotely by registering them with the D-Bus connection and providing them with a D-Bus path.

If the base object path is given as "/org/freedesktop/atspi/accessibles/" then when objects are registered they may be asssigned paths like "/org/freedesktop/atspi/accessibles/AF12BB12". Objects registering with the mapper must de-register the object before it is deleted. This could be done via destroy signals in GObject, or by other means.

The MapperMessageCallback is a function that is called when a message is received from the D-Bus connection. Its prototype may be:

void (*message_callback) (void* object, DBusMessage* message, DBusConnection* connection)

The first argument is the registered object followed by the received message and D-Bus connection.

Caching

The Performance review of D-Bus vs CORBA found that D-Bus was taking a large performance hit per IPC call. To work around this the D-Bus protocol should attempt to reduce the number of small IPC calls that are made.

A good number of methods from the Accessible interfaces are data access, and as such it should be possible to cache the values. However it is not always possible to update these values, as signals may not be available to notify when they change. There are some values that should not change and are suitable for caching:

  • Name
  • Role
  • Role Name

Calls to access these small pieces of data make up a huge amount of the IPC calls made over AT-SPI. These should probably be cached in the Accessible Objects.

Tree Caching

Another way to reduce the number of IPC calls would be to cache the tree of Accessible Objects. In this scenario, when an AT process asked for the root accessible object the entire tree of Accessible objects would be transferred to the AT in one D-Bus call and cached. All access to the Accessible Objects would be through an interface to the cache.

Types and Accessible Interfaces

Currenly Bonobo provides the functionality for determining what interfaces and Accessible Object supports. A replacement for this must be provided. The Accessible interfaces supported should be transferred with the Accessible Object over D-Bus. But these will also have to be stored on the Application side along with the D-Bus object path. This is to check which method calls are valid, and also to provide correct introspection information of the object.

Extended D-Bus work

How much work should be done on generally applicable D-Bus / Component / Bindings libraries?

On one extreme, the work on AT-SPI could proceed without doing any generic work. This is the most likely case. Here all AT-SPI methods are translated into a D-Bus introspection description. Methods are then written to marshal and de-marshal from the D-Bus wire format to a local object structure, most likely GObject. This is probably the quickest way to get things going. The problems are that anyone wanting to use the D-Bus protocol in another language would have to repeat large amounts of the AT/Client library, or provide a wrapper for the GObject version.

The other case is that the AT-SPI work includes standardizing the work of Telepathy in providing extensions to the D-Bus introspection XML. This could allow for richer language bindings to D-Bus interfaces. If accepted widely this might make it easier for others to provide language bindings to AT-SPI by providing automated marshaling of the D-Bus wire format.

Projects that could make AT-SPI D-Bus easier to implement:

  • GObject Introspection
  • Telepathy D-Bus extensions

Accessibility/Documentation/GNOME2/ATSPI2-Investigation/DetailedDesign (last edited 2011-07-21 18:14:01 by JoanmarieDiggs)