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 <[email protected]> Date: Sun, May 25, 2014 at 12:25 PM To: "Zeeshan Ali (Khattak)" <[email protected]> Cc: [email protected], Aaron McCarthy <[email protected]>, Hanno Schlichting <[email protected]>, Thomas Voß <[email protected]>, Bastien Nocera <[email protected]>, Mattias Bengtsson <[email protected]>, Jonas Danielsson <[email protected]> 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) <[email protected]> Date: Sun, May 25, 2014 at 1:02 PM To: John Layt <[email protected]> Cc: Aaron McCarthy <[email protected]>, Hanno Schlichting <[email protected]>, Bastien Nocera <[email protected]>, Mattias Bengtsson <[email protected]>, Jonas Danielsson <[email protected]> Hi, On Sun, May 25, 2014 at 12:25 PM, John Layt <[email protected]> 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 <[email protected]> Date: Mon, May 26, 2014 at 4:23 AM To: "Zeeshan Ali (Khattak)" <[email protected]> Cc: John Layt <[email protected]>, Aaron McCarthy <[email protected]>, Hanno Schlichting <[email protected]>, Bastien Nocera <[email protected]>, Mattias Bengtsson <[email protected]>, Jonas Danielsson <[email protected]> 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 <[email protected]> Date: Mon, May 26, 2014 at 1:43 PM To: John Layt <[email protected]> Cc: "Zeeshan Ali (Khattak)" <[email protected]>, [email protected], Aaron McCarthy <[email protected]>, Hanno Schlichting <[email protected]>, Thomas Voß <[email protected]>, Mattias Bengtsson <[email protected]>, Jonas Danielsson <[email protected]> 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 <[email protected]> Date: Mon, May 26, 2014 at 1:56 PM To: [email protected] Cc: "Zeeshan Ali (Khattak)" <[email protected]>, John Layt <[email protected]>, Aaron McCarthy <[email protected]>, Hanno Schlichting <[email protected]>, Mattias Bengtsson <[email protected]>, Jonas Danielsson <[email protected]> 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/ _______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
