dbus mini-summit at Desktop Summit 2011

[Thiago Macieira]

On Wednesday, 10 de August de 2011 18:12:38 Will Thompson wrote:
> • Let's declare Simon the maintainer! (If he's okay with that.)
> • Split dbus-glib's mainloop integration out and put it in libdbus.

I don't know if this is what you meant here, but Havoc has said before, and I 
support him, that libdbus-1 shall not link to glib. QtDBus cannot rely on the 
glib integration.

> • 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.

If you meant to declare the function as "thread-unsafe", I can introduce my 
own locking around it. That way, the function will not be called at the same 
time from more than one thread.

If you meant that the function should be called always from the same thread, 
you make my life difficult.

> • 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.

One thing I remember now:
 - suicide mode: the D-Bus daemon could exit if there are no non-daemon 
services left. That implies introducing the daemon mode for a service, which 
means its presence doesn't prevent the daemon from exiting.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20110810/deab1c33/attachment.pgp>