GeoClue2

[Eckhart Wörner]

Hi Michael,

Am Sonntag, 17. April 2011, 23:35:16 schrieb Michael Leibowitz:
> You beat me to the punch.  I was about to write a similar email
> discussing a geoclue redesign.  ;)

I won. ;-)

> The GeoClue API/design is not terribly efficient.  One ends up with
> several round-trips around DBUS for any position information.
> Additionally, using DBUS in this way leaks information all over the
> place.
> 
> [...]

I take that as a complement for my proposal, since it doesn't enforce D-Bus 
usage between GeoClue2 and an individual provider anymore.

> The decision making powers and inputs to the Master Provider are too
> simple to give optimal results.  The master provider has no concept of
> latency or power consumption, providers have no basis to specify them,
> and clients have no basis to input their requirements for either.
> Furthermore the resources that providers may request are too course
> grained and rigid.  For example, a satellite position provider might not
> require network access to give information, but having it might enable
> assistance that greatly reduces latency or increases accuracy.> The GeoClue 
API/design is not terribly efficient.  One ends up with
> several round-trips around DBUS for any position information.
> Additionally, using DBUS in this way leaks information all over the
> place.

Why do you think an application knows better than GeoClue2 whether to use the 
network or how much power consumption is acceptable? If the application knows 
that the laptop is on battery, so does GeoClue2, if the application knows that 
there is an internet connection, so does GeoClue2. If there was any other 
essential piece of information which only the application has, there are 
probably some design issues in your stack somewhere else.

> The abstraction of providers also hides provider details.  This sounds
> like the facts of life and a non-problem, but it actually is a problem.
> There are my applications out there that want to display some detailed
> status of their position fix but also want to be able to support several
> positioning methods.  For example, an application might want to report
> the satellites in view if it's getting a GPS signal, but display the
> access points it sees for a wifi based position method.

Except that this information serves no purpose in normal applications which 
are just interested in position information. If you want to write an 
application that shows your full GPS information, you should connect to gpsd 
directly.
(I have seen few people who actually know how to interpret satellite 
positions, which is a strong indicator that this is not something you want in 
your average application's interface.)

> How do you specify accuracy, latency, or power requirements?  When
> creating the objects?  When querying them?

Accuracy is specified as a property in the Provider object already.
(There are some issues in the old API which IIRC freely mixes accuracy and 
precision).

I'm not sure latency is a good idea to add - how do you filter available data 
based on latency? How do you know there is less than 0.1 second delay in the 
bluetooth connection between your gps and your laptop?

As already argued, GeoClue2 should have the same information about the power 
situation as the individual application, and can therefore make the same 
decisions.

> I assume street is a freely encoded house number and street? 

I guess so. Address information has the same semantics as in the old GeoClue.

> Also, how
> do you disambiguate ambiguous replies?

I don't. This is a limitation I took over from the old API.

> > Communication of changes is done via the standardized PropertiesChanged
> > signal.
> 
> What if I'm not interested if some of the properties change?  I don't
> want to be woken up if the compass changes and I don't care about the
> compass.  Might I suggest a more fine-grained approach of specifying
> requirements for change notification as well?

If Heading is neither in ActiveProperties nor in PassiveProperties, the 
property won't be set by GeoClue2 at all (and hence the PropertiesChanged 
signal will never be emitted for it either). The Provider only has a limited 
view on the information available, where the limitations are defined by 
ActiveProperties and PassiveProperties.

> What is to be configured?

The address of your bluetooth GPS, activated providers, the server that is 
used for cell triangulation, …

Eckhart