GeoClue2

[Bastien Nocera]

On Sun, 2011-04-17 at 23:35 -0700, Michael Leibowitz wrote:
<snip>
> 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.

That's an implementation problem, not a D-Bus one. D-Bus allows you to
do peer-to-peer, so information doesn't get leaked from one application
to the other.

> Most of the next round of criticism focuses on getting GeoClue more
> tightly integrated with positioning mechanisms.  This isn't how it is
> presently designed, but as positioning mechanisms in the mobile space
> are becoming more advanced and interrelated, having GeoClue be more
> entwined with the mechanics of positioning will likely be required.
> Actually, I'm mostly focused on positioning, as geocoding/reverse
> geocoding are basically just turning around to a web service typically.

I agree with the fact that geocoding and reverse geocoding should be a
library instead. That would make a lot of sense, and make it easier to
integrate in each environment.

> The GeoClue design of providers makes it such that making hybrid
> positioning methods is difficult if not impossible.  This makes things
> like dead-reckoning between position fixes nearly impossible to
> implement without enabling each provider below the geoclue level.
> 
> 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 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.  This sounds
> contrived, but consider how MeeGo's qt-mobility back-end is currently
> written.  It talks to both GeoClue and Gypsy to report satellite data
> for GPS fixes as well as supporting non-satellite methods.

Trying to hide a GPS behind 2 levels of abstraction is a bad idea IMO.
If your application is complicated enough that it wants to know the
positioning of the various satellites, or wants to parse some of the
NMEA events itself, you're probably talking at the wrong level.

In those cases, I'd much rather see a very static implementation of a
similar API, with the service poking at your hardware devices, rather
than trying to cram support for it into something like Geoclue.

> > == Proposal ==
> > 
> > The GeoClue2 service is the only access point to information; there's no
> > documented way of communicating with individual providers for information
> > retrieval.
> > 
> > The main interface allows to create objects for individual applications. Any
> > object created through the main interface is said to be owned by the
> > respective application and should not be used by any other application.
> > 
> > This is the main interface:
> > 
> > <node>
> >         <interface name="org.freedesktop.Geoclue2">
> > 
> >                 <method name="CreateProvider">
> >                         <arg name="path" type="o" direction="out" />
> >                 </method>
> > 
> >                 <method name="CreateAddressResolver">
> >                         <arg name="path" type="o" direction="out" />
> >                 </method>
> > 
> >                 <method name="CreateCoordinatesResolver">
> >                         <arg name="path" type="o" direction="out" />
> >                 </method>
> 
> How do you specify accuracy, latency, or power requirements?  When
> creating the objects?  When querying them?

What are those power requirements? Again, I think this is too low-level
a thing to have in Geoclue.

<snip>
> I think that making position providers as plugins or at least defining a
> plugin interface should be a goal.  The ability to provide
> high-bandwidth data between different providers to support hybrid
> positioning information will more or less require this ability in order
> for it to be efficient.

We really want to stop having to use D-Bus for communication between the
master provider and the backends. I think that this should all be hidden
away.

> > Configuration is separated from the main functionality. It should not be used
> > by an application, but only by a configuration tool. The interface is yet to be
> > defined.
> 
> What is to be configured?

Most likely things like the baudrate and device node to use to access a
GPS device. I'd want to use GSettings for this, and be done with it.

I'll add my major problem with some of the extensions that were
proposed. What interface are available, right now, to provide altimeter
or compass information? Do some Bluetooth GPSes provide that? Or would
you see that only builtin to devices either through some proprietary
daemon with its own protocol, or through a standard Linux device driver
interface?

I'd be happy buying (or being given) hardware that would provide the
extra interfaces, as long as the plan was clear on what devices can
actually provide.

Cheers