D-BUS spec - comments on wire protocol

[David A. Wheeler]

> I don't really like the protocol version per-message; it should probably
> be negotiated in the auth protocol.

Actually, I think the per-message protocol version is
EXACTLY right - don't change that!

These messages may have been passed on
through others (e.g., one bus passes it on to a filter, who
passes it on to another bus, who passes it to an app, who
passes in through a private socket).  If the version number
is at the beginning, then nobody has to "translate"
between version numbers... you can pass on messages
from "older" and "newer" versions without deeply
understanding them... you just need to find the message end.

If a particular connection has a fixed protocol value,
then to pass on messages you'd have to translate the
messages - ugh.  And if they're digitally signed, you're
REALLY doomed -- you can't translate at all.

Having the protocol version in the prefix of the
message itself is, in my mind, The Right Thing to do.
There's a reason so many other wire formats do it...!
I really believe it's important to KEEP the version number.

Ideally the version number would be the first byte,
If you want to move it, NOW is the time.. you WON'T
be able to move the byte later.  If you want to convince
non-users that D-BUS is a good thing, having this as the
first byte might even help convince people it's a good thing...
because (1) that 's a common convention and (2)
you can show that them that if there's a serious problem
in D-BUS, you can re-monkey the format for their needs later.

> > * 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 suppose so, sure, though you have to require people to mask out all
> the other bits when reading this byte to allow adding flags.

Given that they can add fields, and there are 6 spare bits
in flags, perhaps it's not worth it then.  No doubt SOMEONE
will forget the mask the bits, and cause problems the first
time someone tries to add a bit there.


> > I'm not excited that implementations are FORBIDDEN to
> > accept arrays larger than 2^26 bytes....
> But how does an app "adapt" to that variable limit?

The receiver app doesn't need to adapt to anything, so
clearly this only affects senders and message busses.
If the limit is imposed simply by memory, then that's a limit
they'd have to deal with anyway.

>... it has to be hardcoded until there's a way to request the
> current limit (dbus_connection_get_max_array_size() in effect).

It's actually a limit of the transitive path to the recipient and the recipient,
not just the current connection... which makes a query even harder.

I actually think it's quite reasonable to try to just send the data, and
have the system reply with "fail" if there's a problem.   Heck, even
if an array fits inside the sanctioned size, the system may run out
of virtual memory and not be able to do it anyway.
"Just do it" and reply on failure deals with
transitive closures, avoids having to figure out a query, etc.
It also works in a Unixy way -- just open() and write()... if there's
a problem I'll tell you.  Which is why I suggest simply documenting
a suggested maximum... anyone can try to go beyond, but they've
been warned, and the infrastructure will tell you if it didn't work.

If you think a hard limit is important to set, I suggest appending this
so at least implementors will know that they may need to
change things later:
   (note: future versions of this specification may raise the limit
   if it becomes a problem.)

> To me a better approach than allowing huge arrays would be some kind of
> standard support for streams.

Fair enough, but that may be awkward, and it'd certainly add code.
Supporting unexpected uses without having to change the implementation
has its own advantages.

--- David A. Wheeler