Mikhail Zabaluev wrote: > 2008/3/2, Jussi Kukkonen <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>: > > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
