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