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? > > 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. 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? --Ted
Attachment:
signature.asc
Description: This is a digitally signed message part