dbus mini-summit at Desktop Summit 2011

[Will Thompson]

On 08/08/11 16:50, Colin Walters wrote:
> So Thiago, Will Thompson and I sat down for a few minutes at the
> Desktop Summit here and talked about the current state of DBus as well
> as the future.

Here are some rough notes from the D-Bus BoF; apologies if I've missed
anything.

• Let's declare Simon the maintainer! (If he's okay with that.)
• Split dbus-glib's mainloop integration out and put it in libdbus.
• Declare that using (eg) _send_with_reply_and_block() in >1 thread is
unsupported. We can't actually remove the connection-locking code
because QtDBus depends on it working (inasmuch as it works). VLC (for
instance) uses one private connection per thread, which should continue
to be supported.
• Will will review epoll.
• We could consider exposing a mainloop from libdbus: this might be of
interest to systemd.
• Lennart plans to add ucreds, timestamps, and possibly selinux labels
to messages.
• posix message queues are a potential partial solution to the problem
of prioritizing message processing: higher-priority processes could mark
all their messages as equally high priority. we'd keep causal ordering,
we think… worth investigating.
• user buses:
  ∘ as long as it doesn't change any behaviour in a non-systemd-based
environment, they seem okay.
  ∘ (Aside: Telepathy could avoid having zombie connections if your
Gnome session crashes but your user bus sticks around for whatever
reason by disconnecting if no approvers are running maybe? Or refcounted
presence /o\ )
• Will will polish up the Maybe patches. MPRIS would like to use them,
for instance.
• systemd service activation: Lennart wants to change the code in DBus
to look for systemd service files rather than needing a dummy
DBus-format service file.
• exec: transport seems reasonable. Relatedly, adding feature
negotiation flags to bus address specifications seems potentially neater
than connection_new_with_flags() or similar. For the exec:-via-SSH case
we need to disable FD passing, for instance: the transport string could
end with ",nofdpassing" or similar. This would also permit passing
arguments to feature negotiations in the future.

-- 
Will