KDE Geolocation Services
johnlayt at googlemail.com
Thu Nov 4 15:04:33 GMT 2010
On Thursday 04 November 2010 14:43:19 Kevin Krammer wrote:
> 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
Yes, just to be clear, our api would only call their DBus interface, we would
not use their C api and all the G stuff that would make us depend on directly.
No hard compile or runtime dependencies at all, in fact.
Which kind-of makes the whole GConf usage moot?
> > > 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.
In theory, no concern to us, but we do need to consider what happens if a user
refuses to install the Master Provider due to GConf, or Geoclue at all due to
Glib/GObject. A nice default is always good. No Master Provider, fall back
to a simple guess on what Provider will work best. No Geoclue, try another
bankend, or fall back to a simple hostip implementation, or just return their
preset home location.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
More information about the kde-core-devel