raring has seen the end of its life and is no longer receiving any
updates. Marking the raring task for this ticket as "Won't Fix".
** Changed in: autopilot (Ubuntu Raring)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to autopilot in Ubuntu.
https://bugs.launchpad.net/bugs/1155351
Title:
DBus wire protocol changes required
Status in Autopilot:
Fix Released
Status in Autopilot GTK+:
Fix Released
Status in Autopilot Qt support:
Fix Released
Status in XPathSelect Library:
Fix Released
Status in autopilot package in Ubuntu:
Fix Released
Status in autopilot source package in Raring:
Won't Fix
Status in autopilot-gtk source package in Raring:
Won't Fix
Status in autopilot-qt source package in Raring:
Won't Fix
Status in xpathselect source package in Raring:
Won't Fix
Bug description:
We need to change the DBus wire protocol autopilot uses. This is an
implementation detail that's hidden from test authors, but we need to
make sure we do this in a way that doesn't break things. Read on for a
small novel on why we need to make this change.
Unique Objects
=============
Currently autopilot makes the assumption that the combination of type
name and object id are enough to uniquely identify any object in the
object tree. That is, "Foo[id=123]" will only ever refer to any one
object. In fact, in most cases the id alone would be enough. This has
worked fine, to a point. However, as we move forwards, several cracks
have started appearing:
1) Relative queries are expensive. Some methods, like
'FooClass.get_all_instances()" end up sending a query to the app
that's "//FooClass". XPathSelect has no choice but to search the
entire object tree. This is very slow for large trees. We fixed this
particular problem by deprecating the use of get_all_instances(), and
instead making objects cache the full, absolute path on the server
side. However, as soon as someone uses a partial relative query, any
nodes returned from that query no longer work. For example:
# Fast - aboslute query
/foo
# also fast:
/foo/bar[property=whatever]/baz
# select a 'frob' somewhere under /foo/bar/baz
/foo/bar/baz//frob
# this ^^ is slow, but we expect it to be slow, so that's OK.
The problem is here:
/foo/bar/baz//frob/foo/bar
This is very very slow, since the 'frob' object doesn't know it's full
path, so it cannot use absolute queries on any of it's children. This
makes sub-tree searching slow not only once (for the search call), but
also slow for all subsequent method calls on the returned object.
Current State of Play
=================
Currently the DBus wire protocol is to return a list (possibly empty,
if there were no results) of tuples, one tuple for each object.
Each tuple has exactly two components:
* The object name (e.g.- 'FooClass').
* A state dictionary
A solution:
=========
A simple solution is to change autopilot, autopilot-qt and autopilot-gtk to
return full paths for every object in the search results.
So instead of return [("FooClass", {...})] we'd return
[("/foo/bar/FooClass", {...})]
This path information gets used on the autopilot side.
Impact
======
This has some impact however:
* It means the '/' character cannot be used in an object type name. I don't
think this will be a problem.
* It means we need to make sure autopilot is backwards compatible with older
protocol versions. Currently the AP code to retrieve data over DBus is tightly
coupled with the objects themselves. I'd need to separate this, and provide a
backwards compatibility wrapper.
This bug is a place to track the overall work required for the
separate projects. I suggest we hold off changing autopilot-qt or
autopilot-gtk until the autopilot code has landed (with backwards
compatibility code).
To manage notifications about this bug go to:
https://bugs.launchpad.net/autopilot/+bug/1155351/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
