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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
