dbus_message_demarshal() and partial messages

[Avery Pennarun]

On 16/08/07, Havoc Pennington <hp at redhat.com> wrote:
> Interesting - this is exactly the opposite of what everyone else writing
> dbus bindings is interested in doing (they all want the connection layer
> but not the message marshaling). ;-)

Yeah, the question is if all I'm using is DBusMessage, why not just
rewrite it all from scratch anyway?  I'm just as happy not to, but
it's a question I had to ask myself several times :)

Since parsing/forming binary data is the most likely part to result in
buffer overruns, I'd rather not rewrite my own C++ version of that.
It's obvious that the libdbus code is really carefully written, which
gives me a lot of confidence in its security.

> Taking the perspective of a Linux distribution (or other collection of
> apps packaged as a whole), I do think having bindings or apps
> reimplementing the auth and connection layer is quite bad, because the
> auth and connection layer is where the most "new stuff" is likely to
> happen - new transport mechanisms and auth mechanisms - and it would be
> nice if all apps inherited this work and could talk to each other.
>
> Assuming you are doing something intended to interoperate with dbus at
> all, of course - if not it doesn't matter.
>[...]
> SSL and Windows portability would definitely be "nice to have" in
> libdbus itself, in any case.

One of my goals is to build a "dbus proxy" that will let you connect
the buses of two separate machines together: in this case, Windows and
Linux, or whatever.  For that I need SSL.  But it works with an
existing libdbus/dbus-daemon installation, so libdbus can focus on
what it's most useful for, and people who need more connectivity can
just attach the proxy.

Writing all that code in C (without WvStreams, and to libdbus's coding
standards) would take about an order of magnitude longer, so I'm
afraid I don't have time to contribute that.

> That aside, answering your question - the marshal/demarshal API there is
> intended to tunnel dbus through another protocol like XMPP, it was not
> intended for parsing a dbus stream.
>
> If the API addition to support parsing a dbus stream is trivial then I
> guess we could add it, but I would be reluctant to add much code to
> support this.

Having now done it (I'm linking with libdbus statically so I can
access its internal functions for now), I can confirm that only the
one new function is needed, and its implementation is pretty much
trivial as discussed.

There's also a question of how a serial number gets set: unless I'm
mistaken, dbus_marshal() doesn't set it.  You have to lock the message
first, but that's private too.  dbus_marshal() should do that,
perhaps?

Have fun,

Avery