> 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 _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
