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 _______________________________________________ gnome-accessibility-devel mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
