Skype and DBus: should my client library act as a server?

[Simon McVittie]

On 18/03/15 21:05, Julien JPK wrote:
> While the DBus website clearly states:
> 
> "It should be noted that the low-level implementation is not primarily
> designed for application authors to use."
> 
> ... I thought that library developers could still be an exception to the
> rule: "Rather, it is a basis for binding authors and a reference for
> reimplementations."

"A basis for binding authors" means it is used by the developers of
libraries like dbus-python, QtDBus and dbus-glib, which wrap libdbus in
easier-to-use APIs. (dbus-glib has serious design flaws and is
deprecated, but it was intended to be easier to use than libdbus, and in
some ways it still is - but GDBus is better, so use that instead.)

"A reference for reimplementations" means it is used by the developers
of independent D-Bus implementations like GDBus (C, in GLib), sd-bus (C,
in systemd), dbus-java, ndesk-dbus (C#) to check that their
implementation interoperates with libdbus.

> Do you mean that libdbus should only be used by developers who work very
> closely to DBus itself (developing the daemon, and other key components)
> ?

That is my opinion as a libdbus maintainer, yes.

Not everyone follows this: for instance ConnMan and related projects use
libdbus. I think this is a bad idea, and would recommend not following
their example, but that's their (and your) choice to make.

 Does it mean that application developers are somehow "obliged" to rely
> at least on GLib/GDBus (since all other bindings are even more
> "high-level") ?

You are not obliged to use a higher-level binding like GDBus or QtDBus,
but I would recommend it.

> I'm a bit surprised to see that there is no "approved"
> way to program with DBus while staying at a reasonably low level of
> abstraction...

If you want to program with D-Bus at the lowest possible level of
abstraction, open a Unix socket, connect() to the dbus-daemon's socket,
use sendmsg() and recvmsg() for I/O, and implement D-Bus message
framing, parsing and serialization yourself (see the D-Bus Specification
and the libdbus and/or GDBus source code for details). In practice, I
don't think you want that :-)

Everything beyond that (libdbus, GDBus, QtDBus, etc.) is some sort of
non-essential abstraction - but if we didn't think the higher layers
were valuable, we wouldn't have spent time writing them! To a large
extent, software design is the art of designing abstractions. A
well-designed abstraction guides its users towards good design and away
from traps. Common best-practices should be the easiest; things you
shouldn't do (e.g. sending an unsolicited "reply" when there was no
request) should be difficult; and if you do weird things, it is a
feature, not a bug, if the necessary APIs make you think "hmm, is what
I'm doing a bit weird? could it be done better another way?" while you
write it. Of course, if an unusual pattern is the best way to solve your
particular problem, that's fine, but it is not a bad thing to have had
to think about it first.

You can of course ignore the D-Bus maintainers' advice and do whatever,
but if you subsequently ask us for help, don't be surprised if the
answer includes "that thing you're doing? don't" :-) Some of our advice
is present, in executable form, in the design of the higher-level D-Bus
libraries to which we have contributed: that's a large part of why they
exist.

    S

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>