ubuntu-phone team mailing list archive

[Kevin Krammer <anda.skoa@xxxxxxxxx>]

On Saturday, 2013-12-14, 08:24:03, Thomas Voß wrote:
> On Sat, Dec 14, 2013 at 12:05 AM, Dimitri John Ledkov <xnox@xxxxxxxxxx> 
wrote:
> > On 13 December 2013 22:25, Barry Warsaw <barry@xxxxxxxxxx> wrote:
> >> So, what steps can be taken to avoid such problems in the future, and
> >> what
> >> lessons were learned that might be of use across the project?
> > 
> > dbus apis are hard, hence a few dbus apis are provided as
> > shared-libraries (essentially generate client code and compile it into
> > shared library).
> > When looking at dbus api, as if it's a compiled generated shared
> > library the ABI/API break is obvious and one typically renames the
> > library package as per Debian policy.
> 
> 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.

While it is of course nice to delegate version handling to the linker, it also 
makes writing those interface libraries the difficult task.

A client library like that needs to either hide the asynchronous nature of its 
D-Bus communication by providing a blocking interface or provide an 
asynchronous interface itself.

The former means that developers either have the choice of risking blocking 
their main thread or use a secondardy thread. Also makes it necessary to wait 
for the full roundtrip. See Xlib.

The second option splits into either using threads internally in the library, 
or providing hooks that the library user can call to drive the asynchronous 
IO.
Both make it non-trivial to use the library.

In the case of interal threads the developer needs to deal with getting 
callbacks in a different thread context.
In the case of hooks they need to find a way to either call them regularily or 
attach them to their event loop system.

libdbus is an example for the latter. A library that can be shared across 
different technology stacks but is also considered to complicated to be used 
by application developers directly.

In contrast, a D-Bus API is fully technology stack agnostic, mainly because it 
is a well defined protocol over socket.

Any client developer can use the most appropriate [1] integration technique 
for their chosen technology stack, e.g. event loop integrated (GDBus on GLib, 
QtDBus on Qt), threading (Java D-Bus bindings IIRC).

I am not involved in the development efforts here but having done lots of D-
Bus, application and bindings level, clients and services, my recommendation 
would be to discard the advantage of freedom of technology choice.

It might not be necessary right now, but given Ubuntu's recent change in main 
technology from GLib to Qt you can most likely appreciate not having to build 
wrappers upon wrappers but using native integration capabilities instead.

Cheers,
Kevin

[1] and usually most efficient, since data doesn't have to be transformed and 
copied that often. E.g. Mono and Java implement the wire protocol themselves 
to avoid coping into C types first and then again into their respective native 
types.
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

Attachment: signature.asc
Description: This is a digitally signed message part.