ubuntu-phone team mailing list archive

[Dimitri John Ledkov <xnox@xxxxxxxxxx>]

On 18 December 2013 16:34, 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?

One doesn't typically talk raw dbus calls themself. So one does use
"xml" snippet of the dbus description and generates either
"server-side" or the "client-side" code for the wanted API calls.
Doing it "upstream", results in _all_ dbus exported API to be
available as a library (which would be ABI/API constrained, have
licensing/linking questions, potentially can be large, and be
constrained by the chosen "dbus" higher level API, e.g. nih, gtk
mainloop, Qt mainloop, GIO/gudev technology).

Therefore typically, client facing application import the "xml" dbus
schema for the the things they need, use preferred generator that
makes sense for them, and in no way restricted by the server's
implementation choices of technologies / main-loop apis / license.

In GNOME, it is quite common to auto-generate client libraries, and
have them re-exported again as libraries and girs for C API consumers
& interractive language bindings. E.g. it's much nicer to iterate
across foo_get_all_foos_sync(), then to setup a dbus call / method /
retrieve and parse dbus errors/exceptions and then finally get all
foos ;-) generated client-api libs typically abstract those
intermediate dbus implementation details.

-- 
Regards,

Dimitri.