Proposal: Location hackfest

[Zeeshan Ali (Khattak)]

Bastien forgot to add the list to CC. :)

---------- Forwarded message ----------
From: Bastien Nocera <hadess at hadess.net>
Date: Wed, May 28, 2014 at 12:40 PM
Subject: Re: Proposal: Location hackfest
To: aaron.mccarthy at jolla.com
Cc: "Zeeshan Ali (Khattak)" <zeeshanak at gnome.org>, John Layt
<jlayt at kde.org>, Aaron McCarthy <aaron.mccarthy at jollamobile.com>,
Hanno Schlichting <hschlichting at mozilla.com>, Mattias Bengtsson
<mattias.jc.bengtsson at gmail.com>, Jonas Danielsson
<the.sator at gmail.com>


On Tue, 2014-05-27 at 14:30 +1000, Aaron McCarthy wrote:
> On Mon, 26 May 2014 14:56:08 Bastien Nocera wrote:
<snip>
> > A proprietary source doesn't have to mean a proprietary implementation.
>
> I am aware of that, but sometimes it is out of my control. It would not be
> buildable as it links against proprietary libraries and headers, not
> externally available.
>
> > What sources would you want to use?
>
> The Nokia/HERE WLAN and cellid positioning service.
>
> > If you want to replace a web service in Geoclue by another, the easiest
> > would likely be to ask the provider for an API that's compatible with the 2
> > services we already use.
> > Say you want to replace the Mozilla Wi-Fi geolocation code with Skyhook,
> > and given that Mozilla's service is API compatible with Google's, I'd
> > imagine that vendors have already asked Skyhook for a compatible API to
> > use on Android systems.
>
> The HERE service has a slightly different interface than the geoclocation api.
> Daemons run locally on the device and directly monitor cell towers and WLAN
> APs. Most of the data in the geolocation request would be ignored. It would be
> possible to implement a local service that translates between them.
>
> > If the requirements are more complicated than that, maybe reimplementing
> > Geoclue's API in another D-Bus service would be a better idea.
>
> That would require re-implementing all of Geoclue, no?

Yes, it would.

But given that the Nokia/HERE positioning service pretty much replaces
our use of the Mozilla services in Geoclue, I would implement a
client-side proxy on the client. This would avoid any changes to Geoclue
itself (the server to use should be configurable via a config file), and
allow you to plug in that particular service.

But if you're going to use the Nokia/HERE service, and query the GPS
through a libhybris-wrapped rild, for example, reimplementing Geoclue's
API is certainly worth it. You'd have the same API on desktops and
mobile.

I'll add that, both on ideological and technical grounds, adding a
"plugin" support in Geoclue wouldn't make much sense.

In Geoclue1, we ended up with a bunch of reverse engineered providers
that probably went against those services' ToS, with many overlapping
services leading to impossible to debug problems because the master
provider didn't know what the plugins did internally.

Geoclue2 is supposed to be a whole block of coherent sources, allowing
us to go from one source effortlessly based on the available data, and
also hardware integration. See the Geoclue paragraph at:
http://www.hadess.net/2013/04/geocluing-desktop-slowly.html

> > > > >> Zeeshan wants to know so we can debate whether to add them or not.
> > > > >> Do we
> > > > >> need a separate satellites api (e.g. a pass-through form gypsy) that
> > > > >> we
> > > > >> dynamically query if its available at runtime?
> > > > >
> > > > > If Geoclue2 supports GPS,
> > > >
> > > > Geoclue2 supports GPS only in modems. There is a TODO about adding
> > > > support for standalone GPS devices.
> > > >
> > > > > why not pull the satellite information directly from
> > > > > the NMEA stream. I would prefer that the satellite information comes
> > > > > directly from the same source as the position updates.
> > > >
> > > > Sure, what I was interested in is the use case but yeah, I can expose
> > > > that if needed. Do we want all NMEA traces or only GPGGA?
> > >
> > > Providing access to the NMEA stream would enable application to get access
> > > to data that is not otherwise exposed via the Geoclue2 API.
> >
> > What are the use cases for this? Is it useful for something other than
> > estimating how long it would take for the GPS to get a fix?
>
> For satellite information that would be the main use case. Useful for
> debugging but that's about it.

For this particular use case, I'd rather have better status and progress
indication from Geoclue itself, not something so GPS specific. For
example, whether we're contacting one particular provider over the
network, waiting for a fix, etc.

Can you please file a bug about this use case?

> There is other useful data in the NMEA stream, for application specific use
> cases. The one that immediately comes to mind is the current magnetic
> variation, which is required to calibrate the compass sensor.
>
> > I don't think that Geoclue should be providing API that it cannot
> > guarantee (depending on the modem used, you might not get access to this
> > information).
>
> One of the features of DBus is that you can dynamically publish object paths
> and interfaces. The alternative is to require applications to get this
> information via a separate service. Which service may not be obvious for the
> application.

You say application but your example above of calibrating the compass
sensor is really a system component, not something that applications
should be doing.

But I agree that we can experiment with separate interfaces for very
specific use cases like this one would be useful. There's supposed to be
a separate "debug/management" interface for settings panels to use for
example.

Can you please file a bug about the specifics of this use case (the
compass calibration)?

>  It was mentioned that Geoclue2 currently only supports GPS via
> ModemManager with support for standalone GPS planned. The application would
> need to know which interface/service to use. The application would no longer
> be decoupled from the underlying providers.
>
> > (As I mentioned in the other mail, discussing this on the Geoclue list
> > would be highly appreciated).
>
> I will subscribe.

Cheers