[Telepathy] Geolocation in Telepathy

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
We at the Telepathy project are interested in integrating geolocation
into our presence APIs, implemented using things like
<http://www.xmpp.org/extensions/xep-0080.html>. Since GeoClue is
designing a D-Bus API for geolocation, it would make sense for us to use
the same D-Bus representations for locations.

Our idea for the API so far has been that each Telepathy contact may
have a dictionary of key/value pairs representing their location, with
keys and values defined by some specification (ideally, GeoClue), and
that the local user's client can tell the Telepathy connection managers where
they are in the same format.

The client should pick up the location from GeoClue, direct user input, or some
other source (e.g. whatever API the N810's internal GPS has), apply
appropriate "rounding" according to user preference (e.g. the user could
choose to round off their position to the nearest 1km or 10km or something),
and send it to the connection manager; this is all out of scope for the
connection managers, though. Of course, ideally the "other sources" would
just be GeoClue sources, and the Telepathy client would only have to
care about GeoClue.

So, the Telepathy interface is all trivial, except for defining the
encoding for locations, which is where GeoClue's D-Bus API comes in. I
have a couple of questions about it:

Should we be developing against Jussi Kukkonen's git repository, or the
"upstream" git repository, at this point? For what it's worth, I think
the multiple-interfaces idea in Jussi's repository is a much better
approach than lumping everything together, particularly if there's a
lightweight way to discover what interfaces are supported (i.e.
less unwieldy than Introspect()) - we've been going this route for our
attempts to redesign the telepathy-mission-control component, with a
read-only 'as' property called Interfaces as the lightweight
interface-discovery implementation. (See Account and AccountManager in
the telepathy-spec darcs repository if you're interested)

I notice you've been using fixed-length/fixed-type structs, together with
bitfields to indicate which fields are valid, for Position. We'd been
assuming that location information would be encoded much like you do for
addresses, something like:

  """
  The currently defined keys for this dictionary are:

  'latitude' (d): Latitude according to the WGS84 datum
  'longitude' (d): Latitude according to the WGS84 datum
  'altitude' (d): Altitude in metres above sea level
  'accuracy' (u): ...
  ...

  Keys with no good value should be omitted.
  """

This would solve your problems with indicating which fields made
sense, and allow room for expansion later... or do you consider
proliferation of dictionaries to be too "heavy"?

It would of course be wonderful for our purposes if GeoClue's
representation of location aligned reasonably well with XEP-0080!

    Simon
-----BEGIN PGP SIGNATURE-----

iD8DBQFHxV+6WSc8zVUw7HYRAtfKAJ93nA9g9YwDpQgXqOeNUpIymxzcvgCglWts
9bhrKBFlkX8sJ278/9zR3JU=
=1E+Q
-----END PGP SIGNATURE-----