KDE Geolocation Services

[Kevin Krammer]

On Thursday, 2010-11-04, John Layt wrote:

>  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. 

Ah, you meant using the D-Bus API directly in apps. I interpreted it as in not 
using their C library, i.e. using D-Bus indirectly (through their C wrapper).

> 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.

Common problem when a service has only one client implementation. I guess this 
is also true for most/all of our D-Bus interfaces.

> > 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?
> 
> 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.

I don't think that a service's dependencies are of any concern to us.

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/a543072b/attachment.sig>