First release of geocode-glib available

[Bastien Nocera]

On Mon, 2011-05-16 at 09:37 -0500, Ted Gould wrote:
> On Sat, 2011-05-14 at 21:24 +0100, Bastien Nocera wrote:
> > On Wed, 2011-05-11 at 10:20 +0200, Ted Gould wrote:
> > > On Mon, 2011-05-09 at 16:52 +0100, Bastien Nocera wrote:
> > > > This library should be used in place of Geoclue's D-Bus API for
> > > > geocoding and reverse geocoding.
> > > 
> > > Is this now deprecated in the Geoclue API?
> > 
> > Pretty much, though I can hardly tell KDE people to start using a
> > glib-ish library for that. I would expect them to come up with their own
> > library in due time.
> > 
> > When we have a working new-fangled geoclue to replace the current one,
> > the API (and the old geoclue code) will most likely disappear of their
> > own.
> 
> Why do you think they'd do that rather than just work on GeoClue?

Because I haven't seen any patches from KDE people for now. The new
Geoclue (as discussed on the geoclue list) won't have geocoding or
reverse geocoding interfaces. There's no point in hiding a web service
behind a D-Bus interface when it doesn't buy you anything.

> > >   It seems like there's an
> > > advantage to using an API that can have multiple providers.
> > 
> > The API is generic enough to support multiple providers, it's just that
> > there's currently only one implementation.
> > 
> > The fact that we have only one implementation means that we have one
> > well maintained implementation. I don't think it's much of a problem. Do
> > you have particular reasons why you think that supporting multiple
> > backends is actually useful?
> 
> I don't have a specific use case, but I would guess that name providers
> vary widely based on location.  My guess would be that Yahoo is pretty
> good in the US/Europe but there's a better local provider for
> India/China for instance.  I have no information on that, it just seems
> to be pretty consistent for data like this.

Full list of supported countries:
http://developer.yahoo.com/geo/placefinder/guide/requests.html#supported-countries

Note that this doesn't mean that geocoding isn't available at all, it
just means that street-level isn't supported. It's still good enough for
most of our uses.

> Which is one of the things that struck me as odd with a new library
> being created that didn't use the plugable interface already created.
> Is there a reason you didn't just make a well maintained GeoClue
> backend?

Because we don't want to use Geoclue's geocoding interfaces.