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
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
