GeoClue2

[Michael Leibowitz]

On Mon, 2011-04-18 at 11:49 -0700, Eckhart Wörner wrote:
> Hi Michael,
> 
> Am Sonntag, 17. April 2011, 23:35:16 schrieb Michael Leibowitz:
...
> > 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.

It was certainly not criticism of your proposal, but rather criticism of
GeoClue as it is now.

> > 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 application knows how long it plans to keep listening for location,
which GeoClue doesn't know.  The application knows when it's willing to
trade accuracy, latency, or power consumption.  Simply using accuracy as
a proxy for power measurement doesn't give as much flexibility to choose
the lowest power mechanism.  It also supposes that high accuracy methods
are always the least power efficient.  This may not be true.

Of course, I don't mean to imply that all this decision making power
needs to be directed from the application to GeoClue.  Sometimes it is
just enhancing the interfaces from GeoClue to the underlying system that
would enhance its decision making powers.  Knowing more than "the system
is connected to the internet" could be helpful.  Mobile systems often
have power policies and connection policies that GeoClue could benefit
from interfacing to.  Perhaps we can have facilities like these as more
flexible than they are currently to resemble position providers more.

> > 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.)

I disagree.  I think that not only is this something that could be
trivially added, but isn't a niche thing.  I've seen many a mobile
application that provide some information (useful or not) about their
positioning method.  Additionally, the MeeGo API for location is the
Qt-Mobility Location API.  It is designed to report satellite
information for satellite based fixes.  At present, the implementation
has to talk to both GeoClue and Gypsy to get this information.  This is
suboptimal and it doesn't have to be so awkward to do so.

It doesn't mean that GeoClue should expose NMEA streams to clients or
that GeoClue should have lots of provider specific entanglements.  But
would it be unreasonable for a provider to have a set of properties for
the current status of their underlying mechanism?  The interpretation of
these properties needs not be codified.  It could be as simple as an
array of string->value pairs that a provider can offer to clients.

> > 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).

Right.  But I'm talking about the application side.  An application
should be able to specify how accurate a fix it needs, how soon, and
perhaps some power trade-off information that it can give.

For example, if you are creating a mapping application, you want to
start with the first available position from any source and as more
accurate sources become available, get better and better position.

Consider another case, where you need to do drop a pin so you can
remember where you parked.  Having information that is accurate to
within a few blocks is not helpful.  It's not worth firing up a cell
tower triangulation system to give you position.

> 
> 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?

But when you're in the process of resolving a position, you may start to
get an idea of latent it's going to be.  For example, when you fire up
the GPS and you're not seeing satellites- you know it might be a while.
This could be useful information provided from the provider back to
GeoClue.

> 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.

I would advocate a structured address personally.  Getting this right
with locale and etc is not always trivial.

> > Also, how
> > do you disambiguate ambiguous replies?
> 
> I don't. This is a limitation I took over from the old API.

Might you reconsider?

...

> > What is to be configured?
> 
> The address of your bluetooth GPS, activated providers, the server that is 
> used for cell triangulation, …

This sounds like GeoClue is storing provider information on behalf of
providers.  Why should GeoClue get entangled with such things?  In the
current case, it does because Gypsy has no configuration of its own.  I
see this as a fault in Gypsy- not a reason for GeoClue be a grab-bag of
provider configuration information.

Cheers
-- 
Michael Leibowitz <michael.leibowitz at intel.com>