[GNUnet-developers] Fwd: Re: DBus in GNUnet?

[Andrew Cann]

> My main issue with it at the time was its awkward (and not very stable) C
> APIs, and the fact that I did not want to drag in GLib as a
requirement for
> GNUnet (which is required for the high-level C binding).

The page for the dbus C API says "If you use this low-level API directly,
you're signing up for some pain". I'm not sure why this is, I've worked with
the low-level API before (but never the GLib API) and not had any
problems. The
C API is also fairly stable nowadays.

> DBus also raises questions of security (see #2887), as it is not clear
to me
> how file access controls can be mapped nicely to DBus (but I've simply not
> looked into this).

User/group level access controls can be set with dbus.

> Also, using DBus would not simplify as much as you suggest; parsing the
> configuration is important, as it is the only way we can run multiple
peers
> on one machine for testing. Also, as there is more in the
configuration than
> just the connection information, you'd hardly get around parsing it in the
> long term anyway.

This is true, any language bindings you write would still have to have the
ability to parse the config file. My point was though that for simply
interacting with the services you wouldn't even have to write language
bindings. A python script could, for example, just `import dbus` then start
talking directly to the services.

>  For example, do you know if there is a performance impact (latency,
>  throughput or number of concurrent connections that can be open
system-wide)
>  when using DBus vs. UNIX domain sockets?

DBus uses UNIX domain sockets internally. Any data that gets sent along dbus
passes through two sockets: one on the way to the daemon, then another
back out
to the client. So there is a slight performance impact. Other than that,
it's a
binary protocol so there's almost no impact on throughput or extra time to
construct and parse messages. Also, on linux at least, there are plans
to move
dbus into the kernel so performance shouldn't be a problem after that. On
Windows there is currently a bug open
(https://bugs.freedesktop.org/show_bug.cgi?id=71297) because dbus can only
support up to 64 simultaneous connections due to a limitation in older
versions
of Windows (pre-Vista). That bug also suggests that there is no such
limitation
on linux.

> I don't see an easy path for a gradual transition either...

You could add dbus support to services individually one-by-one. Take a
service,
give it a dbus interface, then migrate all the other services to use its
dbus
interface instead of its socket interface, then remove the socket interface
altogether. Then do that for each service. It would definitely take a
while but
it wouldn't involve breaking everything for a long period of time.

If I started submitting patches to add dbus support to some service
would you
accept them?

 - Andrew