General question on D-Bus design considerations

[Lennart Poettering]

On Sat, 21.08.10 04:31, Kybernetik Kollektiv (kybernetikkollektiv at googlemail.com) wrote:

> I have a general question for the designers/developers of the D-Bus
> specification: What would you do different compared to the current
> design of D-Bus, if you could or had to start the development of D-Bus
> from scratch today?

I wasn't involved in the original design, but here are a few things that
came to my mind, what I'd have done differently. But mentioning these
things here and now is cheap, since in retrospect everything is easier.

- I'd have defined an interface and member type name, similar to how
  there is an object path type ("o").

- The introspection stuff isn't fun, mixing static and dynamic stuff in
  the same XML stuff is not really the best thing to do I think. XML is
  just awful anyway, but might have some validity if it is was used for
  static method signatures only.

- I'd have weakened the security model a little. The current model
  implies that access verification cannot be done by the receiving side,
  but must be done by some bit of trusted code that sits in
  between. That makes it unnecessarily difficult to get rid of the
  proxying process that dbus-daemon is. If it wasn't for the security
  policy it would be really easy to rework D-Bus to sit on top of the
  current AF_NETLINK socket system while getting rid of dbus-daemon.

- I am not very happy with the authentication protocol. I wished we had
  something there that would allow fire-and-forget auth.

- Would have been cool to have the user vs. session thing figured out
  right from the beginning ;-)

- org.freedesktop.DBus.ListNames() should return the owners of the
  names.

But well, some of this is just nitpicking and much of it could actually
still be added to the current spec.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.