← Back to team overview

touch-packages team mailing list archive

[Bug 1155351] Re: DBus wire protocol changes required

 

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: xpathselect (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