GNOME Bugzilla – Bug 652777
Consider moving IPC / AT-side functionality into ATK
Last modified: 2021-06-10 11:25:05 UTC
If ATK were used as the AT-side interface, rather than having a separate API (ie, libatspi), then it would be possible to move all of the IPC-related code into ATK. This would have the advantage that, when API changes are made, only one module needs updating (aside from ATK implementors and ATs). Right now I can't think of a reason why this would not work, although currently ATK is just a set of interfaces that does not define any IPC. So we would either need a client-side ATK implementation that would implement the IPC (ie, the libatspi part of at-spi2-core would move into ATK, and the API would change) or some kind of generic code to marshal an ATK object over D-Bus. If the latter were used, then there would be performance considerations (caching of properties and children should be supported, in particular, and, if gdbus performance is slower than libdbus, then that would also cause a performance hit).
Some IRC discussion: <Company> API: i have a question that you might know the answer to: <API> Company, hi, shot <Company> why does libatspi exist? <Company> my naive idea was that everybody talked directly via the ATK apis <Company> so gtk provided an ATK implementation, and then the bridge would use it to do IPC <API> no, libatspi is the library that AT tools use to talk with AT-SPI2 <API> ie orca doesn't use ATK <Company> and then on the AT side the bridge would provide an ATK implementation and the ATs would use ATK again <API> no, the last one no <Company> but why not? <API> <Company> so gtk provided an ATK implementation, and then the bridge would use it to do IPC <API> this is correct <API> but in the case of ATs like Orca <API> they use libatspi <API> well, in this case pyatspi2 <API> to get the accessibility information from at-spi2 <Company> right, but why was the decidion made to bypass ATK on the client side? <API> well, in general because not all the applications are implementing ATK <API> for example JAVA <API> when ATK was created <API> it was heavily based on JAVA accessibility <API> AFAIK <API> joanie coould confirm that <API> so, at-spi2 was the common field <API> the daemon ATs could ask for information <API> ATK+atk-bridge was the way gobject libraries communicates with at-spi2 <API> and JAW <API> or the java-bridge <API> the way that java applications uses to communicates with at-spi2 <API> and in fact <API> right now <API> qt have a qt-bridge <API> in order to communicate qt apps with at-spi2 <API> but all this is in one side of the equation <Company> yeah, it seems that currently the only thing that everybody speaks is the dbus protocol <API> ATs doesn't want to know this details <API> they just ask at-spi2 (via libatspi) for that information <Company> right <API> well, at this moment <Company> and i was wondering why they go via libatspi <Company> instead of via ATK <API> what it is true is that this abstraction worked well with the corba-dbus move <API> I mean that both gail and cally were abstracted of that <API> Company, well, in summary because ATK is not the only accessible interface here <API> in fact, and about that IA2 <API> I guess that it would be possible to create a ia2-bridge <API> with at-spi2 <API> although not sure if it is worth <Company> i always thought that a benefit was that when the diagram looked like this: <Company> AT <=ATK=> AT daemon <=DBUS=> bridge <=ATK=> application <Company> you'd have the same interface on both sides <Company> and could even try to cut out the middle man and maybe let the AT talk to the application directly <joanie> To be honest API, I've always wondered why ATs didn't talk ATK.... I bet there's a darned good reason why though. ;-) (So I might not be the best person to confirm anything) <Company> i mean, in theory you could implement a screen reader as a plugin <API> Company, as a plugin of an app <Company> yeah <API> so you are proposing that all the apps would require to write their screen-reader plugin? <Company> no <Company> all the apps talk ATK <Company> or possibly talk ATK <Company> and if they do, we can use the plugin <Company> otherwise we use dbus <Company> at least that would be a possible benefit of having ATK on both sides <API> ok, so you are thinking on a common screen-reader plugin <API> well, the problem here is avoid all those running plugins talking at the same time <API> orca right now is also managing app switching and so on <joanie> what? <API> and about that diagram <Company> another benefit would be that when you need to add a feature, you'd add it to ATK, and then both sides have access to it, you don't need to modify ATK _and_ libatspi <joanie> app switching? <API> hmm, yes I didn't explain myself properly <API> what I mean is that with the current approach you onlhy have one screen reader talking <API> with a plugin approach <API> you will have n-screen readers that could talk <Company> yeah, the plugin approach was just an example <API> and it would be required to coordinate them in some way <joanie> ah <API> company, about this diagram: <API> <Company> AT <=ATK=> AT daemon <=DBUS=> bridge <=ATK=> application <API> yes it makes sense <API> as it would be easier to document and so on <API> and we would maintain just one interface instead of two <API> I think, <Company> right <API> but remember that I was not here when all this stuff started <joanie> ;-) <API> is that libatspi was defined in that way <Company> yeah, i was just wondering why it was that way :) <API> due corba idl <API> so libatspi in that moment was just mostly the idl interfaces <API> and cspi mostly the c-bindings for those interfaces <Company> yeah, that's another thing that surprised me <API> and right now at-spi2 requires some cleaning <API> ie, it still have those idl directory <Company> how much all the code was scattered around <API> but <API> afaik, idl are not used anymore <API> it was used at the begining <API> of the corba-dbus move <Company> yeah, that explains it <API> in order to automatically create something based on the previous interfaces defined <API> I thinhk that I read something about that when it was defined <API> anyway, right now at-spi2 is mostly a one-man project <API> and current mgorse work is awesome taking into account that <API> he is using his spare time to take care of it * Company wonders how much work it would be to move all this stuff into ATK <API> well, as I said, mgorse is the expert here, so he would be the one that could answer that <API> anyway, as usual, this is also about prioritize <API> so not sure if this is the most important task here <API> desired yes, top 1, not sure <Company> it's also about challenging myself, because i'm waaaaay more productive when challenged <Company> ;) <API> well, in that case a top 1 challenge would be awesome <API> ;) <API> btw, I have just realized something of that diagram <API> <Company> AT <=ATK=> AT daemon <=DBUS=> bridge <=ATK=> application <API> as you are removing one DBUS communication, and about that plugin idea <API> it seems that you are suggesting that AT should be plugins of the daemon <API> instead of the current approach of having a AT - Daemon communication via DBUS <API> Company, ^ <Company> no, that was not what i meant <Company> maybe more like: AT <=ATK=> what libatspi does today <=DBUS=> bridge <=ATK=> application <Company> where "AT <=ATK=> what libatspi does today" is run inside the AT process <Company> and "bridge <=ATK=> application" is run in the application <API> so you still proposes <API> AT <=ATK=> DBUS => AT daemon <=DBUS=> bridge <=ATK=> application <Company> yes <API> aha, well, just checking <API> it would be good, imho <API> if we get somehow to avoid two dbus messages <API> on any app event <Company> also <Company> we can change the middle part all we want later <API> yeah, just saying, and as other ideas in mind, that would be a long-term solution <API> but the fact is that right now one of the big issues here is performance <API> although, AFAIK (not real data ), it is something that in general affect DBUS <API> at least compared with ORBit <Company> yeah, performance is the other thing i have to understand <Company> are there any demos explaining the problems <Company> preferrably something that runs on the command line and then returns how long it took and doesn't require user interaction?
(In reply to comment #0) > If ATK were used as the AT-side interface, rather than having a separate API > (ie, libatspi), then it would be possible to move all of the IPC-related code > into ATK. Could you provide an example of that IPC-related code? What kind of things would be required to be moved to ATK? Will this code add a dependency to the specific IPC technology (CORBA in the past, DBUS now, HypotheticalFancyThing in the future)?
It would mean migrating/porting the code presently in at-spi2-core/atspi and at-spi2-atk. That's a good point, that it could add an IPC dependency to ATK. If dbus is used for the IPC, then this could be handled by gdbus (already in glib), but I think this would currently incur a major performance hit over the current libatspi and atk-bridge implementations (see bug#634471; improving gdbus performance may happen but seems to be a low priority for everyone, including me, since it works to keep using libdbus).
(In reply to comment #3) > It would mean migrating/porting the code presently in at-spi2-core/atspi and > at-spi2-atk. Probably is because too late in this timezone, so sorry if this is a stupid question. But in that case, what would remain on at-spi2-core?
Currently we have the following in at-spi2-core: - libatspi - at-spi2-registryd - introspection data (which could be used for documentation or to auto-generate introspection.c in at-spi2-atk) - "idl" which has some information about the IPC not found in the xml; could be used to auto-generate documentation or enums but isn't. Another option would be to put some of this back into the xml and generate documentation and enums from that.
[Mass-reassigning open atk bug reports for better trackability as requested in https://bugzilla.gnome.org/show_bug.cgi?id=653179 . PLEASE NOTE: If you have watched the previous assignee of this bug report as a workaround for actually getting notified of changes in atk bugs, you yourself will now have to add atk-maint@gnome.bugs to your watchlist at the bottom of https://bugzilla.gnome.org/userprefs.cgi?tab=email to keep watching atk bug reports in GNOME Bugzilla. Sorry for the noise: Feel free to filter for this comment in order to mass-delete the triggered bugmail.]
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of atk, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/atk/-/issues/ Thank you for your understanding and your help.