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

[Julien JPK]

On 19/03/15 10:50, Simon McVittie wrote:
> 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 :-)

On 18/03/15 21:35, Thiago Macieira wrote:
> Reality is that it's actually easier to write your own socket and
> marshalling code.

Actually, if I had more experience with DBus, and had spent more time
studying it, I'd be very interested in writing a C implementation
focusing more on application development than it does on internal DBus
development.

On 19/03/15 10:50, Simon McVittie wrote:
> 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. 

Again, I don't believe these abstractions are uninteresting. I'd go even
further: I think they're essential. After all, what kind of universal
IPC solution would DBus be if it only allowed "pure C" programs to
communicate with each other?

What I find a little restrictive however, is that the C programmer finds
himself trapped between two extremes when his work doesn't involve DBus
as a central component: using the frowned-upon libdbus, or big GDBus.

Consider a very simple program doing basic statistics, but using DBus as
a "data source." In this case, DBus is merely here to provide data to
work on, but the program's main task is not DBus-centric (as it would be
the case for a "secondary Skype client", for instance).

In this case, libdbus looks like the obvious solution: the API is
available in C, and with some patience, it becomes rather easy to use.
It doesn't require anything more than C knowledge, and minimal
understanding of the DBus specification: it's perfect if I'm not making
DBus a central part of my program.

The recommended solution however would be to use GDBus, especially if
I'm using threads. Yet, this means that I need to bring GLib into my
simple C program, and that's quite a deterrent... Not to mention that I
would probably have to rewrite the rest of my program with GLib, since
mixing the library with non-GLib C isn't really good looking...

Nevertheless, I don't believe that GDBus is the one solution when
working with threads in C. Expecting libdbus to work identically in both
single-threaded and multi-threaded contexts is, in my opinion, wrong. I
don't expect POSIX messages queues, shared memory, and sockets to be
usable across threads without mutexes and semaphores, and there's no
reason for DBus to be any different in the eye of the C programmer. By
including pthread.h, I know that I'll need to protect the DBus
connection, and for that, I need to understand when, and how libdbus is
using it (which is what Thomas Downing seems to have done in his work).

This point of view, however, is irrelevant if I involve GLib or Qt.
These libraries/frameworks are expected to handle such tasks for me, and
their DBus implementation should behave the same way. If one of my
threads calls the dispatch routine, I expect other threads to be blocked
shall they try to use the connection in a way that could disturb the
dispatching (or at least, I expect an easy protection mechanism to be
provided). I don't have such an expectation in C, and I shouldn't.

This is why I was very surprised to see that libdbus was strongly
advised against: as a C programmer, it behaves exactly as I expect it
to. I don't expect the library to protect itself against threading
trickery. I simply expect it to help me communicate with the DBus
daemon. If I don't protect this "communication flow" myself, my program
*will* behave strangely, and it should be no surprise.

Thank you again for your input on this. Thomas Downing's implementation
of a multi-threaded libdbus program was quite interesting as well,
especially the way the work is distributed among threads. Lars Hanisch's
example of VDR was a good one as well: in this case, I do believe that
switching to GDBus/QtDBus was interesting, because the application could
use GLib/Qt for the rest of its components. There isn't really any
overkill there.

-- 
Julien Kritter (PGP key 0xC3075A58)
julienjpk at email.com