ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Wed, Dec 18, 2013 at 5:34 PM, Barry Warsaw <barry@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>