Re: Issues with capability bits and meta-data in kdbus

[Havoc Pennington]

On Wed, Apr 22, 2015 at 10:35 AM, Michele Curti <michele.curti@xxxxxxxxx> wrote:
>
> Just out of curiosity, would you like to change something in dbus design,
> if you didn't have to worry about ABI breaks and the like?
>

Good question. I can't remember any big-picture things, I'm sure the
current maintainers and users have a longer list. :-) There are a
variety of little small things, some examples I can immediately think
of:

 * the ad hoc authentication protocol is sort of ugly
 * the byte order marker in every message is silly
 * protocol version in every message is useless
 * Ryan Lortie's nice fixes in GVariant, which I think kdbus adopts (
https://people.gnome.org/~ryanl/gvariant-serialisation.pdf ), for the
most part these are 'cleanups' but nullable types ("maybe" types for
Haskell fans) are a notable semantic addition
 * specify how it works on Windows, the Windows port last I checked
(years ago) didn't do things in a Windows-sensible way
 * specify what happens when resource limits are reached
 * wouldn't use XML for introspection data these days
http://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format

The implementation has more problems:

 * libdbus had a flawed goal (be the underlying implementation used by
higher-level libs), it turns out it's better to implement the protocol
in every lib, libdbus was trying to serve too many masters. libdbus is
slow and has an annoying API, and the protocol is simple enough for
every "stack" (glib, python, etc.) to implement it themselves.
 * rethink what happens when hitting resource limits in the bus
daemon, as discussed in an earlier sub-thread
 * OOM handling code in the daemon is quite a burden, maybe there's a
better way http://blog.ometer.com/2008/02/04/out-of-memory-handling-d-bus-experience/
 * config file format, security policy stuff... work to do here

Havoc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/