Messages in this thread | | | From | Havoc Pennington <> | Date | Wed, 22 Apr 2015 16:02:34 -0400 | Subject | Re: Issues with capability bits and meta-data in kdbus |
| |
On Wed, Apr 22, 2015 at 10:35 AM, Michele Curti <michele.curti@gmail.com> 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
| |