On Wed, Dec 18, 2013 at 5:34 PM, Barry Warsaw <ba...@ubuntu.com> wrote: > On Dec 14, 2013, at 08:24 AM, Thomas Voß wrote: > >>Seconded. Treating DBus as an implementation detail and not leaking it >>to customers of your service helps a lot in versioning access to your >>API/service. In addition, our tooling and packaging supports >>versioning on a library/symbol level quite nicely. > > I'm curious, is that the only -- or main -- reason to implement a wrapper > around a D-Bus API or are there other benefits, especially to compiled apps? >
Well, that and avoiding leaking implementation detail is always a good idea. If you expose a DBus API to clients you cannot easily migrate users of your library/service to (1.) newer versions or (2.) adjusted implementations. You are pretty much committing to that implementation detail for a long time. On top, DBus assumes a remote peer to be running, which is not necessarily the case on the phone, given our strict lifecycle policy. Admittedly, this is not the case for app -> service, but it holds true in general. With an API in place you can easily provide an internal buffering scheme transparently to the API consumer. Thomas > -Barry > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-phone@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
