D-BUS spec - comments on wire protocol

David A. Wheeler dwheeler@dwheeler.com
Fri Jan 21 08:31:34 PST 2005


I just took a look at the new spec (0.9), and I like many
of the improvements.  I like the "type signatures" work;
I notice that the Perl bindings ended up exposing that anyway,
so it's nice that the "type signatures" are clearly explained
(I'd expect that any binding exposing type signatures at all
would use the same format).  I particularly like the fact
that the header itself is defined using a type signature;
that's an excellent sign, that it can describe itself.

However, I suggest some changes in the header:
* The FIRST byte should be the "Major protocol version"
   (currently the FOURTH byte).  Many protocols always
  start with a major protocol version number (e.g., IP),
  so that if you find out you need to change it massively
  later, you can do so.  Otherwise, you have the weird
  case of "looking in byte 4 to see what byte 1 means".
  I think "major protocol version" values are important,
  because they give you built-in flexibility.. if later on you
  find out there's a critical problem, you can create a
  new format without forcing an unworkable "flag day"
  on all users.
* The SECOND byte should probably be endianness,
   (early in case there are problems),
  THIRD message type, FOURTH for flags.
   Endian-ness is early so that the rest can be correctly
   interpreted, and message-type before flags so that
   the flags' meanings will make sense (in case they
   depend on the message type).
* Wouldn't it be better if "endianness" was a simple bit,
  say the LSB of the endianness byte?
  That way, if you run out of room in the "flags", you
  have some spare bits.

I'm not excited that implementations are FORBIDDEN to
accept arrays larger than 2^26 bytes.  Clearly sending a document
is NOT the expected use of D-BUS, but forceably creating arbitrary
limits is often not a great idea unless there's a security issue,
which isn't suggested here.  I suggest changing
the array text to this: "Implementations and users SHOULD not
send arrays larger than 2^26 bytes, and implementations MAY refuse
to accept arrays larger than 2^26 bytes."

P.S.: Is something wrong with the mailing list server? I see your
personal replies, but not the mailing list copies, and messages seem to
not be posted to the Archives.

--- David A. Wheeler


More information about the dbus mailing list