geocode-glib: Geocoding, reverse geocoding library

[Bastien Nocera]

On Sat, 2011-04-23 at 21:40 +0100, John Layt wrote:
> On Thursday 21 Apr 2011 22:05:48 Bastien Nocera wrote:
> > The current code uses json-glib, libsoup, and gvfs (for HTTP), though I
> > can remove the gvfs requirement if MeeGo/KDE people are interested in
> > the code.
> 
> It is possibly something KDE could be interested in, although Bastien might be 
> in a better position to comment on that.

If there's a Bastien other than me in this discussion, I'd be very very
surprised :)

> As a general word of advice from experience, if you want even the possibility 
> of other projects using a library you write then you need to make it as 
> generic as possible right from the start and with a clear design separating 
> the core and platform-specific parts.  Even temporary solutions as a quick 
> hack using familiar technology have a bad habit of hanging around long after 
> they were intended (i.e. GeoClue and gconf :-).
> 
> Just on the whole KDE situation, we've been looking into gelocation again and 
> this has led to one of our devs trying to work up a patch to remove the gconf 
> and gsettings dependencies.  The patch proposal should turn up in the next 
> couple of weeks for discussion.

The GConf dependency is already gone. And I wouldn't take a patch to
remove the GSettings dependency. There's Qt bindings to access
GSettings, and GSettings lives in GIO, which is also where the dbus-glib
replacement (GDBus) lives. I don't think that trying to replace a
library that's already in the dependencies due to the way packages are
built is buying us anything but too moving parts.

> P.S. Oh, and Quikee: that probably means no Vala, sorry.

As much as I don't like Vala for its API instability, it's not a
run-time dependency, it's a compile-time dependency for people compiling
from git (eg. you'd ship the pre-processed C files in tarballs).