DBus wire protocol changes required

[Thomi Richards]

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).

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:xpathselect at revision 32, scheduled for release in xpathselect, milestone Unknown

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:autopilot at revision 165, scheduled for release in autopilot, milestone 1.3

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:autopilot-qt at revision 53, scheduled for release in autopilot-qt, milestone Unknown

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:autopilot-gtk at revision 34, scheduled for release in autopilot-gtk, milestone Unknown

[Launchpad Janitor (janitor)]

This bug was fixed in the package autopilot - 1.3daily13.06.05-0ubuntu2

---------------
autopilot (1.3daily13.06.05-0ubuntu2) saucy; urgency=low

  * autopilot-touch only suggests python-ubuntu-platform-api for now.
    It's not in distro and we need that requirement to be fulfilled to
    have unity 7, 100 scopes and the touch stack to distro.
 -- Didier Roche <email address hidden> Fri, 07 Jun 2013 13:33:46 +0200

[Rolf Leggewie (r0lf)]

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".