I am still a little confused, though. It seems that Geoclue, in its current form, offers both geocoding, reverse-geocoding, calculating velocity and a few other things (hard to figure out what exactly just from the wiki).
In that context it is not clear why we need a separate geocode-glib, and then why do we need to move the GeoIP code from geocode-glib back to geoclue.
Not that I am suspicious of your intentions or anything. ;-) Just that it is a bit confusing for the casual reader.
We're separating it because there's no point in having a small wrapper around web APIs in a daemon.
We could either have exposed the API through D-Bus, introducing an unneeded level of indirection, or offered the API through a library, which wouldn't have been usable (or needing to be wrapped) for people that didn't use GObject in their projects.
A stand-alone library makes sense in that case.
As for moving the GeoIP code to Geoclue, geocode-glib was just a holding place for it (as mentioned in the post), and we don't want application developers to rely on it (for the reasons mentioned in the blogpost).
Unknown: as one of the original developers of geoclue (who hasn't been contributing in a long time though) I totally support this move. With hindsight the geoclue architecture tried too much and did not achieve the final goal of Just Working: we always suspected that that might require having at least one platform/product where you clearly know your data sources and can optimize for them (and then make it degrade nicely): this never really materialized so the code is a lot of abstraction for little benefit...
As Satabdi's program is now finished (though not her involvement!), and a new GNOME development cycle has started, I'll try to explain where geocode-glib fits in, and answer some questions on the future of Geoclue.
(Reverse-)Geocoding
First and foremost, geocode-glib is a geocoding and reverse geocoding library. It uses Yahoo! web services for this, though we're investigating using Nominatim for this in the future.
This replaces the convoluted implementations for those two services in geoclue (3 if you include Address as a service). The API should be mostly stable now, and we'll soon start porting a few applications to it (Evolution and Empathy come to mind).
The library also includes a GeocodeLocation object. This will be useful later.
GeoIP
geocode-glib, thanks to Satabdi's work, includes a GeoIP server, to be installed on GNOME servers eventually, which uses data from MaxMind to locate a user connected to the Internet from the IP address. We also have a client library to access this server.
This is usually good enough to locate a user in a city, or a country, which would help us with many integration points in GNOME, such as the upcoming Date and Time panel re-design.
But this code isn't really for you, app developers.
Geoclue
A fine project, but the codebase is showing its age (dbus-glib!), and the decision, well, not to take decisions on which backends to use for various services make it fragile. This is a maintenance problem, both for in terms of making sure all the services are kept working, and that geoclue itself is kept stable.
So we'll start a reimplementation of Geoclue. The goals are:
Trimmed down API, just for positioning
Smaller, but more integrated, selection of ways to get the positioning (GPS from your integrated WWAN modem, Wi-Fi AP data, IP address, no discrete GPS or manual location)
Power-saving, by aggregating requests from all the applications
and finally, privacy, where only applications that you allow to request your location can get it, and only with an accuracy as needed for the application.
The code currently in geocode-glib for IP geocoding will likely move there when the project has been kickstarted.
I hope this clears any misconceptions people might have about geocode-glib, or, more likely, about the future of geoclue.
"Geocluing the desktop, slowly"
3 Comments -
I am still a little confused, though. It seems that Geoclue, in its current form, offers both geocoding, reverse-geocoding, calculating velocity and a few other things (hard to figure out what exactly just from the wiki).
In that context it is not clear why we need a separate geocode-glib, and then why do we need to move the GeoIP code from geocode-glib back to geoclue.
Not that I am suspicious of your intentions or anything. ;-) Just that it is a bit confusing for the casual reader.
4 April 2013 at 02:42
We're separating it because there's no point in having a small wrapper around web APIs in a daemon.
We could either have exposed the API through D-Bus, introducing an unneeded level of indirection, or offered the API through a library, which wouldn't have been usable (or needing to be wrapped) for people that didn't use GObject in their projects.
A stand-alone library makes sense in that case.
As for moving the GeoIP code to Geoclue, geocode-glib was just a holding place for it (as mentioned in the post), and we don't want application developers to rely on it (for the reasons mentioned in the blogpost).
4 April 2013 at 07:56
Unknown: as one of the original developers of geoclue (who hasn't been contributing in a long time though) I totally support this move. With hindsight the geoclue architecture tried too much and did not achieve the final goal of Just Working: we always suspected that that might require having at least one platform/product where you clearly know your data sources and can optimize for them (and then make it degrade nicely): this never really materialized so the code is a lot of abstraction for little benefit...
4 April 2013 at 09:53