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 > wrapper).
Phew! 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. John. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
