ubuntu-phone team mailing list archive

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

On Sat, Dec 14, 2013 at 12:41 PM, Kevin Krammer <anda.skoa@xxxxxxxxx> wrote:
> 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.
>

Sure, it takes effort for a library or service author to provide a
client API that is easy to use and versioned.
But in the end, it is a service offered to consumers of the
library/service, taking away the burden to deal with
internals of an implementation.

> 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.
>

I disagree here. If the DBus internals are exposed, the developer has
to deal with exactly the same problems, on a much less convenient
level. In addition, we would be forcing developers into one of our
technology choices that might change over time. Exposing internals
does not solve the problem and versioning is not captured by our
default tool chain. With that, I have a hard time understanding the
benefits of being "lazy" and not providing a client 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.
>

I think it's a contradiction to call a *DBus*-API technology-agnostic,
but that's only my pov.

> 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).
>

Sure, but do we want developers to worry about this? I think it is
much easier to consume an API that does not leak implementation
details. On our side, it is easier to maintain, too. We only ever
commit to the public facing API, accepting the effort to provide such
an interface, solving the versioning problem with a well-known and
established toolchain.

> 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.
>

Appreciated, but that does not solve the original versioning issue. As
I tried to point out before, leaking the DBus protocol leads to tight
coupling which in turn renders the versioning task even more
difficult.

Thanks,

  Thomas

> 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
>
> --
> 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
>