[Telepathy] Geolocation in Telepathy

[Jussi Kukkonen]

Mikhail Zabaluev wrote:
> 2008/3/2, Jussi Kukkonen <jhkukkon at cc.hut.fi <mailto:jhkukkon at cc.hut.fi>>:
> 
>     Using a dictionary for position data is somehow compelling, but I am
>     worried about the "heaviness" and somehow it feels conceptually wrong: a
>     Position is latitude/longitude (and possibly altitude) in WGS-84, not a
>     varying collection of values like Address... That said, it is an
>     interesting idea, one that I hadn't thought of.
> 
> Let me expand on that, using your code example:
> 
>         pos.get_position (&time, &lat, &lon, &alt, &accuracy)
> 
> 
> What alt receives here if the provider lacks altitude data? How to tell
> if it does?

Sorry, I was just trying to show the general flow and left that bit out.
The C function looks like this:

    GeocluePositionFields
    geoclue_position_get_position (GeocluePosition  *position,
                                   int              *timestamp,
                                   double           *latitude,
                                   double           *longitude,
                                   double           *altitude,
                                   GeoclueAccuracy **accuracy,
                                   GError          **error);

where the return value is a validity bitfield. So a check for altitude
validity would be "if (retval & GEOCLUE_POSITION_FIELDS_ALTITUDE)". The
D-Bus signature looks like this:

    <method name="GetPosition">
      <arg type="i" name="fields" direction="out"/>
      <arg type="i" name="timestamp" direction="out"/>
      <arg type="d" name="latitude" direction="out"/>
      <arg type="d" name="longitude" direction="out"/>
      <arg type="d" name="altitude" direction="out"/>
      <arg name="accuracy" type="(idd)" direction="out"/>
    </method>

> Then, if we consider Python bindings, a straightforward binding would
> turn the above into:
> (time, lat, lon, alt, accuracy) = pos.get_position()
> 
> Not very convenient if you need only some of those values.

Not much of a python developer myself, so I can't judge how inconvenient
that is...Would you say it's difficult for the binding to wrap that in a
way that would be more natural to a python developer?

> I would prefer some kind of a compound value returned, which then could
> be mined for data as necessary. It'd also be better, perhaps, for
> dynamic language bindings. I can't see where data structure overhead
> would become a performance concern, until there's an API that calls for
> passing massive position lists. Maybe, separate types for 2D and 3D
> positions could be helpful too, if the freeform dictionary approach
> looks undesirable.

You may well be right about performance... Like I said I hadn't even
considered this before friday. Do you have other reasons why a compound
value would be better, apart from the dynamic language bindings issue?
Simon mentioned possible API expansion, but I just can't see that as
major threat with Position -- unlike Address, where we can't really know
what people will want to include: this is why we're using a hashtable there.


Thanks,
  Jussi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20080303/57c3e9e1/attachment.pgp