GNOME Bugzilla – Bug 649805
Would be good to provide a way to invalide the cache
Last modified: 2011-05-24 22:35:42 UTC
In some occasions accessibility developers found out that they got wrong values, and they suspect that it is because the cache is not properly updated. Although most of the times this is a problem on the application, having a way to confirm it by invalidating the cache could be useful.
(In reply to comment #0) > In some occasions accessibility developers found out that they got wrong > values, and they suspect that it is because the cache is not properly updated. > Although most of the times this is a problem on the application, having a way > to confirm it by invalidating the cache could be useful. First, I completely agree that being able to prevent any caching between AT and app is a very useful ability. However, I'm not sure I'm comfortable with the idea that the AT knows about caching intermediate layers are doing. imho how caching works should be private to the implementation, and so not exposed through an api. It seems like this sort of thing could be a problem when / if libatspi ever wants to change how it caches. Another thing that worries me about this is that I suspect AT's would end up using this flushCache() to hack around broken applications. My first idea of a alternative to do this is an enviroment variable LIBATSPI_NO_CACHE=1 which when set would cause libatspi to do no caching. The disadvantage of this approach is that you would need to atleast restart theAT being used for teesting for this to work, but that might not be so bad. I supose libatspi could flush its cache on a signal SIGUSR1 but immho a library that installs signal handlers for the life of the program is both rude and likely to be broken, so I don't believe this is an option that should be taken
(In reply to comment #1) > (In reply to comment #0) > > In some occasions accessibility developers found out that they got wrong > > values, and they suspect that it is because the cache is not properly updated. > > Although most of the times this is a problem on the application, having a way > > to confirm it by invalidating the cache could be useful. > > First, I completely agree that being able to prevent any caching between AT and > app is a very useful ability. However, I'm not sure I'm comfortable with the > idea that the AT knows about caching intermediate layers are doing. imho how > caching works should be private to the implementation, and so not exposed > through an api. It seems like this sort of thing could be a problem when / if > libatspi ever wants to change how it caches. AFAIU, we are not asking to expose something so complex. As far as I see it it would be something like a method "clean cache", and internally the implementation would expand it. It would be something similar to the "clean cache" on firefox. You just ask to clean the cache, but nothing more complex would be exposed. > Another thing that worries me > about this is that I suspect AT's would end up using this flushCache() to hack > around broken applications. Well, right now one of the problems of accessibility is the performance, and a lot of work was done on cache in order to solve that. So I don't see that as a big problem, as doesn't seem too practical. > My first idea of a alternative to do this is an > enviroment variable LIBATSPI_NO_CACHE=1 which when set would cause libatspi > to do no caching. The disadvantage of this approach is that you would need to > atleast restart theAT being used for teesting for this to work, but that might > not be so bad. I supose libatspi could flush its cache on a signal SIGUSR1 but > immho a library that installs signal handlers for the life of the program is > both rude and likely to be broken, so I don't believe this is an option that > should be taken Yes this is also a good option. Not sure if using a environment library, but somehow ask at-spi and atk-bridge to not cache.
ATK Hackfest conclusions: * It would be good to do for 2.2. * Mike will take a look. * This could be a valuable tool for developers of ATK implementations (e.g. as opposed to having to quit and restart Accerciser) * Orca users could notice that the data seems stale and execute a to-be-created comment to refresh the buffer/cache.
I've done the following: - added atspi_accessible_clear_cache into libatspi. This will clear the cache for the given accessible and its descendants. Passing the desktop accessible will thus clear the cache for all applications. - Added a clearCache alias in pyatspi. - Added a check for ATSPI_NO_CACHE at initialization time; if this is set in the environment and not 0, then all caching will be disabled.