[Marble-devel] Re: KDE Geolocation Services
johnlayt at googlemail.com
Thu Nov 4 14:51:26 CET 2010
On Thursday 04 November 2010 09:01:12 Kevin Krammer wrote:
> On Wednesday, 2010-11-03, Aaron J. Seigo wrote:
> > 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.
Sure, the DBus calls would return you the information you need, but I feel it
would impose a higher level of knowledge on the app coder, they would have to
understand Geoclue itself to know how to work it, set it up, call it,
understand the returned data, then use it. It would also allow us to provide
convenience classes for things like Coordinate, Location and Address that
integrate and work properly, rather than having each app creating their own
possibly buggy versions. It would also give us Qt-ish things, like nice
signals passing a Location everytime a location changes. We'd then have only
one place where we generate the QDbus adaptor instead of 50, only one copy of
the template set-up/tear-down code instead of 50, and only one place that
needs maintenance if/when Geoclue changes. [I do need to read more on how
QDbus stuff works, I'll admit that :-)]
It's more about making it easier for the coder than there being anything wrong
with using DBus.
Funnily enough, I went looking for examples of the DBus calls required for a
simple location query, and even the Geoclue website doesn't provide any, they
only show how to use the C interface.
> > 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
> Do the D-Bus calls transport GConf keys?
No, I understand it uses it for storing some internal config for the Master
Provider, there's no GConf stuff in the dbus calls. In fact, I think it even
provides a dbus api for changing the Provider config (which are not in GConf)
which that Master Provider also responds to. So we wouldn't have to deal with
GConf at all, it's just an implementation detail at their end, but also an
added dependency we may not want, but is entirely optional is we're willing
to write our own Master Provider.
More information about the Marble-devel