KDE Geolocation Services

[Kevin Krammer]

On Wednesday, 2010-11-03, Aaron J. Seigo wrote:
> On Wednesday, November 3, 2010, Kevin Krammer wrote:
> > On Wednesday, 2010-11-03, John Layt wrote:
> > > The obvious backend solution is Geoclue, a freedesktop.org project
> > > which is available on almost all distro's now, is used by Gnome, and
> > > is an official part of the Meego platform.  The problem comes in the
> > > api to access Geoclue, which is a DBus based service with C bindings,
> > > as we would obviously prefer a Qt-ish C++ wrapper for convenience.
> > 
> > What kind of problem do you have in mind regarding a service with a D-Bus
> > API? There are already tons of these and they are using D-Bus as the
> > primary API exactly because it allows developers on different technology
> > stacks to use their preferred way of handling the protocol.
> 
> a) annoyance of using DBus directly

It's a single line in the CMakeLists.txt, isn't it?

> b) changes in the DBus API are out of our control.

Sure, but upstream API changes are always out of our control.

Anyway, neither of these would impose a problem of having a Qt style API for 
the service.

> that said, what dependencies does Geoclue have these days? it used to
> depend on gconf, which would be a highly unfortunate dependency for
> kdelibs to acquire. it was said a few years (!) back that this dependency
> would be easy to remove and would likely be. has it been?

This sounds weird. I have to admit I don't know anything about the Geoclue 
architecture, but how would a service implementation detail become a client 
dependency?
Do the D-Bus calls transport GConf keys?

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101104/449283ef/attachment.sig>