GeoClue2

[Bastien Nocera]

On Sun, 2011-04-24 at 10:48 +0200, Guilhem Bonnefille wrote:
> Hi all,
> 
> I'm (not yet) a GeoClue user, nor a GeoClue contributor. So, I do not
> really have spoken permission. But I will try to add my opinion about
> this really interesting discussion thread.
> 
> IMHO, reading these mails, it seems that the thing missing is "What
> geoclue is?" before "How geoclue is designed?". I think these mails
> show that some questions must be answered before going further.

It wanted to be all things. But it should rather be a way to hide serial
GPS, A-GPS embedded in 3G device, Bluetooth GPS, network location
detection, etc. from the application developer.

> For example: at what abstraction layer work geoclue? Should it is at
> hardware level or not?
> he most relevant example is the "power" matter.
> About this specific problm, I have two opinions to decide:
> - in a service oriented architecture, there is no matter to use many
> services at a time

Doesn't parse.

> - in a service oriented architecture, services should not overlap

Again, doesn't parse.

> - "power" matter is not specific to geolocation related hardware
> (think about WiFi chipset or GSM chipset)

No, but if we can avoid using the Wi-Fi chipset when already have a GPS
enabled for other reasons, all the better.

> For these reason, I think power has nothing to do in geoclue "public"
> interfaces. In its implementation, a provider can play with power
> consumption if it want, for example to adapt to acuracy requests, but
> it is its internal issue and client should just express the acuracy it
> wants.

It should be hidden inside the Geoclue implementation, yes, but "hiding
it" inside each provider is a recipe for disaster. If I'm already
connected to a network via Wi-Fi, and the applications asks for a
"country" accuracy, then I'd probably want to use the network to try and
detect the location, rather than fire up the GPS.

> Other important question is what sort of services are provided by
> Geoclue. Reading the list is not clear if geocoding/reverse geocoding
> is part of Geoclue or not.

It was, and it won't be.

> IMHO, Geoclue can try to address all geolocation related services like
> positionning, heading, geocoding, reverse geocoding, routing, etc.
> Why? Because D-Bus abstraction is a really good solution to share
> code, much more than libraries.

Libraries work just fine. If you want to hide your library behind a
service after that, be my guest.

> But these services should be isolated in really distinct interfaces.
> 
> And then come the matter of raw device data (NMEA, number of
> satellites, access point id...).
> In a service oriented point of view, these data should not be exposed
> by Geoclue, if its role is to abstract from hardware. These data
> should be exposed by other services (like gypsi).
> At the same time, like suggested in the list, it could be interesting
> to expose a sot of generic interface to expose these data in a sort of
> key=value array, in a non standadized way (no standard name fo keys).
> 
> 
> Sorry for a long email. I hope it will help this so usefull poject.

Cheers