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 _______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
