Fwd: Proposal: Location hackfest

[Zeeshan Ali (Khattak)]

Hi everyone,

Forwarding the relevant bits from a discussion about needs of Qt and
Jolla from Geoclue2 here. Lets continue discussion here from now own
or add 'geuclue list' to CC if you reply to earlier emails on this
thread.

Forwarded conversation
Subject: Proposal: Location hackfest
------------------------
...

From: John Layt <jlayt at kde.org>
Date: Sun, May 25, 2014 at 12:25 PM
To: "Zeeshan Ali (Khattak)" <zeeshanak at gnome.org>
Cc: aaron.mccarthy at jolla.com, Aaron McCarthy
<aaron.mccarthy at jollamobile.com>, Hanno Schlichting
<hschlichting at mozilla.com>, Thomas Voß <thomas.voss at canonical.com>,
Bastien Nocera <hadess at hadess.net>, Mattias Bengtsson
<mattias.jc.bengtsson at gmail.com>, Jonas Danielsson
<the.sator at gmail.com>


Here's Aaron's comments on whet he believes are missing from the GeoClue2 api.

> * What features are we really missing from the GeoClue2 api?

I understand that GeoClue2 doesn't output position updates at regular
intervals instead updates are emitted when the position changes by a minimum
amount. I would like to see it support both. Time based updates are useful
because:

 * existing application expect time based updates, the Qt API expects time
   based updates
 * it is the mode of operation that the positioning hardware operates in
 * it may have power saving implications

GeoClue1 didn't support sending all position requirements to the providers.
>From a Qt API perspective an application could request say satellite
positioning at an update interval of 5 seconds. GeoClue1 would use the
satellite positioning request to start the appropriate provider, but it didn't
pass the 5 second update interval through. What this means is that, for
example, the GPS device is always powered up and outputting updates every
second. Some GPS device have the option to power off if the update interval is
sufficiently large and power on in time to get a new fix.

GeoClue1 supports external position providers. My understanding is that
GeoClue2 has a single positioning daemon with all providers built in (maybe as
plugin?). This is useful for implementing proprietary because of license
requirements and run-time security restrictions.

Having GeoClue2 automatically select the best available provider that the
applications request.

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

John.

----------
From: Zeeshan Ali (Khattak) <zeeshanak at gnome.org>
Date: Sun, May 25, 2014 at 1:02 PM
To: John Layt <jlayt at kde.org>
Cc: Aaron McCarthy <aaron.mccarthy at jollamobile.com>, Hanno Schlichting
<hschlichting at mozilla.com>, Bastien Nocera <hadess at hadess.net>,
Mattias Bengtsson <mattias.jc.bengtsson at gmail.com>, Jonas Danielsson
<the.sator at gmail.com>


Hi,

On Sun, May 25, 2014 at 12:25 PM, John Layt <jlayt at kde.org> wrote:
> Here's Aaron's comments on whet he believes are missing from the GeoClue2 api.

Cool. Thanks for forwarding. My comments below:

>> * What features are we really missing from the GeoClue2 api?
>
> I understand that GeoClue2 doesn't output position updates at regular
> intervals instead updates are emitted when the position changes by a minimum
> amount. I would like to see it support both. Time based updates are useful
> because:
>
>  * existing application expect time based updates, the Qt API expects time
>    based updates
>  * it is the mode of operation that the positioning hardware operates in
>  * it may have power saving implications
>
> GeoClue1 didn't support sending all position requirements to the providers.
> From a Qt API perspective an application could request say satellite
> positioning at an update interval of 5 seconds. GeoClue1 would use the
> satellite positioning request to start the appropriate provider, but it didn't
> pass the 5 second update interval through. What this means is that, for
> example, the GPS device is always powered up and outputting updates every
> second. Some GPS device have the option to power off if the update interval is
> sufficiently large and power on in time to get a new fix.

Ah ok. You make a good case for this so I'll look into that. With
ModemManager, we currently need to explicity enable/disable the modem
and that is pretty bad as apps have no way of knowing if another app
(including system components) is using the modem or not. I suggested
to Aleksander that ModemManager should keep track of all applications
and automatically enable/disable modem based on that info. So what we
could do here is that Geoclue tells ModemManager it doesn't need the
Modem during the interval specified by the (geoclue-using) app.

With ofono, I'm not sure how that would work as I haven't checked the
API. Would you know?

> GeoClue1 supports external position providers. My understanding is that
> GeoClue2 has a single positioning daemon with all providers built in (maybe as
> plugin?). This is useful for implementing proprietary because of license
> requirements and run-time security restrictions.

We currently don't have plugin support but I'm more hoping we don't
need external provides but rather geoclue be able to use all available
external sources: ModemManager, ofono etc. For WiFi geolocation, we
have been using NetworkManager for getting list of wifis around and
Mozilla Location Service for querying location based on that list. As
part of this hackfest, I completed the work to use wpa_supplicant
directly instead of NetworkManager so I'm hoping that helps in
portability a lot already.

Geoclue uses the geolocate API (compatible with Google's geolocation
API) and its possible to tell geoclue to use some other service
through the config file.

However, if there really is a usecase for allowing pluggable sources,
we can certainly look into that.

> Having GeoClue2 automatically select the best available provider that the
> applications request.

Not sure if you are asking or telling but its true. :)

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

----------
From: Aaron McCarthy <aaron.mccarthy at jolla.com>
Date: Mon, May 26, 2014 at 4:23 AM
To: "Zeeshan Ali (Khattak)" <zeeshanak at gnome.org>
Cc: John Layt <jlayt at kde.org>, Aaron McCarthy
<aaron.mccarthy at jollamobile.com>, Hanno Schlichting
<hschlichting at mozilla.com>, Bastien Nocera <hadess at hadess.net>,
Mattias Bengtsson <mattias.jc.bengtsson at gmail.com>, Jonas Danielsson
<the.sator at gmail.com>


Hi,
I don't know if ofono provides such an API. That way it is implemented in
Jolla/SailfishOS is that the GPS device is accessed directly and not via
ofono. Hardware-wise the GPS closely connected to the modem. From user space
this is only exposed when the GPS device is informed of which mobile data APN
is connected and should be used to download assistance data.

> > GeoClue1 supports external position providers. My understanding is that
> > GeoClue2 has a single positioning daemon with all providers built in
> > (maybe as plugin?). This is useful for implementing proprietary because
> > of license requirements and run-time security restrictions.
>
> We currently don't have plugin support but I'm more hoping we don't
> need external provides but rather geoclue be able to use all available
> external sources: ModemManager, ofono etc. For WiFi geolocation, we
> have been using NetworkManager for getting list of wifis around and
> Mozilla Location Service for querying location based on that list. As
> part of this hackfest, I completed the work to use wpa_supplicant
> directly instead of NetworkManager so I'm hoping that helps in
> portability a lot already.
>
> Geoclue uses the geolocate API (compatible with Google's geolocation
> API) and its possible to tell geoclue to use some other service
> through the config file.
>
> However, if there really is a usecase for allowing pluggable sources,
> we can certainly look into that.

I'm looking at this from the perspective of integrating a proprietary position
source. Geoclue1 provided a clear separation between closed proprietary code
and the GPL/LGPL code.

> > Having GeoClue2 automatically select the best available provider that the
> > applications request.
>
> Not sure if you are asking or telling but its true. :)

Geoclue1 didn't do it in both directions. Gracefully dropping back to less
accurate position source when the more accurate sources stop providing
position updates. That is once it got a position fix from the best available
source, say GPS, it stayed on that source indefinitely. Even after the fix was
lost for some time.

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

Cheers,

--
Aaron McCarthy

----------
From: Bastien Nocera <hadess at hadess.net>
Date: Mon, May 26, 2014 at 1:43 PM
To: John Layt <jlayt at kde.org>
Cc: "Zeeshan Ali (Khattak)" <zeeshanak at gnome.org>,
aaron.mccarthy at jolla.com, Aaron McCarthy
<aaron.mccarthy at jollamobile.com>, Hanno Schlichting
<hschlichting at mozilla.com>, Thomas Voß <thomas.voss at canonical.com>,
Mattias Bengtsson <mattias.jc.bengtsson at gmail.com>, Jonas Danielsson
<the.sator at gmail.com>


On Sun, 2014-05-25 at 12:25 +0100, John Layt wrote:
> Here's Aaron's comments on whet he believes are missing from the GeoClue2 api.
<snip>
> GeoClue1 supports external position providers. My understanding is that
> GeoClue2 has a single positioning daemon with all providers built in (maybe as
> plugin?). This is useful for implementing proprietary because of license
> requirements and run-time security restrictions.

Please explain the "license requirements and run-time security
restrictions" that would be involved here.

> Having GeoClue2 automatically select the best available provider that the
> applications request.
>
> > 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, 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.

But, what is the satellite information useful for (other than passing
all the information we could ever get in the hope that it's useful to
applications)?

By the way, all those discussions should happen on the geoclue
mailing-list.


----------
From: Bastien Nocera <hadess at hadess.net>
Date: Mon, May 26, 2014 at 1:56 PM
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>


Hey,

On Mon, 2014-05-26 at 13:23 +1000, Aaron McCarthy wrote:
<snip>
> I don't know if ofono provides such an API. That way it is implemented in
> Jolla/SailfishOS is that the GPS device is accessed directly and not via
> ofono. Hardware-wise the GPS closely connected to the modem. From user space
> this is only exposed when the GPS device is informed of which mobile data APN
> is connected and should be used to download assistance data.

Which means that the GPS can't be used if there is Wi-Fi signal but no
mobile signal? I think the exact steps for "enabling" (or making
available) the GPS device to applications that use Geoclue is slightly
different on a computer, and on a "always connected to the GSM network"
mobile phone.

> > > GeoClue1 supports external position providers. My understanding is that
> > > GeoClue2 has a single positioning daemon with all providers built in
> > > (maybe as plugin?). This is useful for implementing proprietary because
> > > of license requirements and run-time security restrictions.
> >
> > We currently don't have plugin support but I'm more hoping we don't
> > need external provides but rather geoclue be able to use all available
> > external sources: ModemManager, ofono etc. For WiFi geolocation, we
> > have been using NetworkManager for getting list of wifis around and
> > Mozilla Location Service for querying location based on that list. As
> > part of this hackfest, I completed the work to use wpa_supplicant
> > directly instead of NetworkManager so I'm hoping that helps in
> > portability a lot already.
> >
> > Geoclue uses the geolocate API (compatible with Google's geolocation
> > API) and its possible to tell geoclue to use some other service
> > through the config file.
> >
> > However, if there really is a usecase for allowing pluggable sources,
> > we can certainly look into that.
>
> I'm looking at this from the perspective of integrating a proprietary position
> source. Geoclue1 provided a clear separation between closed proprietary code
> and the GPL/LGPL code.

A proprietary source doesn't have to mean a proprietary implementation.
What sources would you want to use? 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.

If the requirements are more complicated than that, maybe reimplementing
Geoclue's API in another D-Bus service would be a better idea.

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

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

(As I mentioned in the other mail, discussing this on the Geoclue list
would be highly appreciated).

Cheers





-- 
Regards,

Zeeshan Ali (Khattak)
________________________________________
Befriend GNOME: http://www.gnome.org/friends/