GeoClue2
Guilhem Bonnefille
guilhem.bonnefille at gmail.com
Sun Apr 24 01:48:22 PDT 2011
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.
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
- in a service oriented architecture, services should not overlap
- "power" matter is not specific to geolocation related hardware
(think about WiFi chipset or GSM chipset)
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.
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.
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.
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.
More information about the GeoClue
mailing list