On 11/05/2013 12:58 AM, Magdalen Berns wrote: > > Would need to be replaced by > selection = accessible.get_selection_iface() > if (selection): > <get the selected object using the selection interface> > else: > <use a fallback to get the selected object> > > * Registry.registerEventListeners allow to register more than one event > on one call. > * All the utility methods at utils.py > * etc > > Thanks! I think something similar was done to make the javascript > bindings work because the name's of some of the interfaces (and maybe > their methods - I can't remember off the top of my head) could not share > the same names as those already existing in gnome-shell javasscript.
As you said that you didn't remember, this is the commit you are talking about: https://git.gnome.org/browse/at-spi2-core/commit/?id=5b9c1723 And that change was possible because there wasn't any other app using atspi javascript bindings, and because we had the manually created python bindings. That is basically a big API change, but Orca was not affected because it was manually wrapped. >> As far as I know, the only surprise that the author found, was that DBUS >> was event slower than expected. But in any case, he was already waiting >> DBUS being slower. > It was a bit more than that, but my main point was that taking errors > into account should explain surprises. i.e. if the results are > surprising the experimental method is likely to be flawed. Well, probably it is a subjective opinion, but I don't agree. Take into account the abstract of his analysis: "I have been under the impression that the CORBA IPC/RPC mechanism used by the GNOME desktop environment was bloated and slow. People have commented that the DCOP and DBUS were speedier alternatives." So he thought that DBUS was faster than DBUS. And he did all those experiments to confirm that theory. And this was his conclusion: "For repeated calls to a particular RPC function, the C bindings to the Orbit2 orb outperform calls using the C++ bindings to DCOP and DBUS." So the surprise came from the fact that the empirical tests showed that he was wrong on his initial assumption, not because the experiment itself was wrong. Having said so, we also need to take into account that those tests are giving a really narrow perspective of the performance hits. It is only measuring common methods of the accessibility framework individually, in order to directly measure the performance of CORBA vs DCOP vs DBUS. But as I said on my previous email, a good test suite should also analyze which and how many times those accessibility methods are called. > > > 7. Actual codes get written to implement changes decided in 6. >> This is not clear. As I said, one of the ideas of measuring, is testing >> a possible change. > I just meant at that stage people would finally be able to act on the > information discovered by taking tests and analysing the results. > Essentially what I was driving at was that without the information there > is nothing anyone can be sure of so it is probably worth answering the > questions and, if that can be done sooner rather than later it may be > worth it in the long run. Then we are at a egg-chicken problem. You are saying that without answering the questions, we can't measure. I'm saying that I would like to use the measures to found where are the possible problems, so questions. Because in sort this is the situation: Problem: some people thinks that GNOME accessibility framework performance should be better. Hypothetical solution: improve the performance of the current performance bottlenecks. Question: where are those bottlenecks? My suggestion was using something similar to what was done in the past [1] to found those bottlenecks, and the use that test suite to ensure that we don't regress on any future change. Using the same scheme: Problem2: we want to improve the GNOME accessibility framework API Hypothetical solution2: there are two possible APIs Question2: is API1 worse that API2 in terms of performance? Is any of them worse to current state? BR [1] https://wiki.gnome.org/Accessibility/Documentation/GNOME2/ATSPI2-Investigation/IPCResults -- ---- Alejandro Piñeiro _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
