[g-a-devel] Not so easy: About pyatspi2 deprecationg and the merge of ATK and AT-SPI

[Piñeiro <apinheiro igalia com>]

Hi everybody,

yesterday we had another chat about pyatspi2 deprecation, and the merge
of ATK and AT-SPI. Joanie mentioned that we talk about this now and
then, and some people need to be refreshed about the reasons of "why not
now?", and that it would be good to have it written. So I'm sending this
email, so we could share our toughts, and can be the basis of a wiki page.

So I wil go on this as a kind of FAQ.

1. Why can't we just deprecate pyatspi2 and start to use gobject
introspected bindings?

As far as I know, pyatspi2 adds some wrapping over the pure
gobject-introspected calls. Some were done to fix some reentrancy
problems (although as far as I see those were moved to libatspi itself)
and other bugs. As mentioned yesterday, it is all about moving those
fixes to libatspi itself. In any case, there are some python-specific
wrapping, "utilities" like the emission of meaningful python exceptions,
that probably will be lost.

But the main reason, imho, is that as this mail subject is saying, we
are considering merging ATK and AT-SPI, being something more similar to
ATK the more likely "survivor". In any case, that would mean an API
change. So it would be better to have that merge clear, in order to
avoid ATs (Orca/accerciser) needing to do the port twice. Becuase this
is a good amount of job. Event on the case of keeping libatspi, python
gobject introspected bindings and pyatspi2 API are not totally equal.
Porting apps like Orca and Accerciser would be a really big amount of
work. So we need to be sure of what we are doing before starting.

2. What are the reasons to merge ATK and AT-SPI?

The main reasons is that atk and libatspi are really similar, meaning
that in most cases, a change on one means a change on them, and their
derivatives. For example, adding a new role need changes on atk,
at-spi2-core, at-spi2-atk and pyatspi2. There are a kind of "GNOME
accessibility spec" abstract idea, that is somewhat defined on several
similar libraries.

So the idea would be have just one header library. Then toolkits would
have an implementation for the server side, and at-spi would have a
implementation for the client side.

3. So why not just decide for one and use it?

Because although they are really similar, they are not equal. There are
several differences between atk and libatspi API. On the case of the
client/server different functionality, it is as easy as having different
headers for each (and properly document the purpose of them). But there
are cases not so easy to solve. For example, one tricky one is how
polymorphims are implemented on both. atk uses inheritance. libatspi
uses composition.

What that means? Lets use as example the Text interface:
 * On atk there are some objects that are text objects. Those objects
implement a specific interface, AtkText. And those objects know that
implement that interface when they are created. In order to know if a
object is a text object, you just need to use glib macros like this:
ATK_IS_TEXT(object). And then in order to use it you just call atktext
methods, because they are of the right type.
* On libatspi there are some objects that are text objects. But to know
if it is a text object, you don't use glib macros. You use a libatspi
method. And in order to use it, you ask for an atspi-text object. So the
API exposes the text interface as a separate component. In the practice,
it is returning the same object, and atspi-accessible objects just
implement all the interfaces, but the API exposes the functionality as
composition, so it is not really "pure composition", but is a
composition API after all. That is slightly less type safe, because you
can call libatspi-text methods on a object that doesn't implement that
interface.

libatspi approach has an obvious advantage. When you create the object,
you don't need to worry about which speficic interfaces it implements,
it is an almost empty object. And which interfaces implement are
requested only if needed, with a new DBUS call (GetInterfaces).

And as we want to merge both, the question is, which approach do we want?
 * atk approach:
     + more type safe
     + after creation doesn't need a new DBUS call to know which
interfaces implement.
      - bigger creation overhead: it would be needed to know which
interfaces the object implements when it is created. That means sending
more info for each object created
 * libatspi approach:
      - less type safe.
      - after creation needs a new DBUS call to know which interfaces
implement
     + smaller overhead on object creation, as it only request which
interfaces needs if needed. One could argue that most of the objects
will need this call. But this doesn't need to be true. Applications
creates tons of accessible objects, and just some of them are
interesting to the AT.

So as you can see both approaches has pros and cons. So the tricky
question: which use? On that specific example, in order to decide, we
would need to make some benchmarking, similar to this old one:
https://wiki.gnome.org/Accessibility/Documentation/GNOME2/ATSPI2-Investigation/IPCResults

4. What happens with Qt?

Yesterday Luke asked what would happend with Qt. I said that it will not
be really affected, as it is reimplementing the DBUS communication,
without using libatspi at all. Since yesterday I was thinking a little
and I realized that this is not totally true. And looking at atspi-qt
code I confirmed it. It is true that it doesn't use libatspi methods,
but it use libatspi constants. Using my previous example with roles,
atspi-qt is using libatspi headers in order to know how to map Qt
accessibility roles to atspi roles. In any case, qt have a dependency to
this library, if we get that "one library to rule them all", qt would
just need to change one for the other. In any case we would need to ping
Frederik.

5. Why not autogenerate the headers for this just one library using the
xml spec?

I think that this was suggested by Benjamin some time ago. The
explanation: at-spi2 provides all their funcitonality as a DBUS service.
As with most of dbus programs all the functionality are defined on some
xml files. This is really similar to what happened in the past with the
idl files (CORBA/orbit related) at at-spi1. So one idea would be a step
forward, and create most of the headers of this new library from those
xml files. That would mean that most of the functionality would be added
to those xml files, and then the headers (and probably more stuff),
would be generated from them. I say "most functionality" because likely
we would still need to maintain some of it. In any case, I have the
feeling that current libatspi has as starting point those xml files.
Mike, could you confirm that?.

As far as I know, last releases of dbus-glib and gdbus improved a lot on
those kind of things, and tracker is doing something really similar to
that. But we would need to take a look to that.


CONCLUSIONS
=========

Reducing the amount of places to update each time the GNOME
accessibility spec changes makes sense, would be a good idea, and it is
worth investigate it. But taking into account all the still not answered
questions, the amount of work that would need, and all the priorities we
have right now (like Wayland), probably this is not the best moment to
focus on this.

Comments, questions, doubts, feedback in general?

----
Alejandro Piñeiro