[g-a-devel] Some thoughts about deprecating pyatspi and moving to introspected libatspi

[Piñeiro <apinheiro igalia com>]

Hi,

last week we talked about that during IRC and it was also an item on the
weekly meeting. Mike Gorse has an action item to make some
investigation, but meanwhile I would like to start a little debate as
part of that investigation.

One of my concerns is related with the plan of stopping to have two
different accessibility API. This is explained in this bug [1], but in
summary, using Benjamin diagram, what we have right now is this:
 
AT <= libatspi => AT daemon <=DBUS=> bridge <=ATK=> application

So in the server side (application) we have an ATK object, and in the
client side (AT) we have a libatspi object, with the same purpose and
just slightly different. The reasons of having two different APIs for
the same are AFAIK, historical, due the way idls was used on the Corba
based AT-SPI. So we concluded that it would be good to check if it would
be possible to get rid of one of those APIs. So maintaining ATK, we
would have an ATK object at the application side, and a equivalent ATK
object at the AT side. One less API to maintain etc. But we are still
working on the details.

Well, my concern is the following one. If we deprecate pyatspi2 and more
to a gobject-introspected libatspi, ATs like Orca and Accerciser would
require to make an effort to change to that new library. If we
eventually get rid of atspi in favor of  a client-side implementation of
ATK, ATs would require to make a new port. This seems like doing twice
the same work, and we already know that our resources are scarce.

So as far as I see, we have two options:

a) Conclude that ATK move to the client-side will take too much and go
on with the current plan to deprecate pyatspi2 and use
gobject-introspection bindings for at-spi. Port ATs. If in the end ATK
is used at the client side make a new port.
b) Conclude that doing two ports doesn't worth. Focus first on moving
ATK to the client side. Deprecate both pyatspi2 and libatspi. Port ATs
to gobject-introspection based bindings for ATK.

Thoughts?

Finally I would also want to mention something about those details we
are working on. On that bug [1], Mike mentions that one solution could
be move all the IPC related code to ATK. And as I mention to the bug,
that would mean add a new IPC dependency on ATK. IMHO, we don't need to
move all the IPC code to ATK to get rid of atspi API. One option could
be just have a client-side ATK implementation. So:
  * ATK keeps being the abstract accessibility API. Represents
accessibility objects.
  * On the server side, different toolkit implements ATK.
  * On the client side, atspi also implements ATK, taking care of the IPC.

Thoughts?


[1] https://bugzilla.gnome.org/show_bug.cgi?id=652777

-- 
Alejandro Piñeiro Iglesias