Google "Protocol buffers" over D-bus?

[Thiago Macieira]

Em Sábado 19. Setembro 2009, às 21.30.08, Ville M. Vainio escreveu:
> Google "protocol buffers", in case you haven't heard of them, are
> basically a way to encode struct-like data in binary form, coupled
> with an IDL-ish description language & code generators.
> 
> http://code.google.com/p/protobuf/
> 
> Now, I'm thinking of the performance implications of passing
> protobuf-encoded byte blocks as (complex) arguments for (and return
> values to) dbus methods. This may, or may not, lead to bandwidth
> improvements over just using the usual dbus stuff
> (dbus_message_iter_append_basic, ...), while still retaining the
> convenient dbus semantics (service discovery/naming, activation,
> method call semantics...) - but with simpler transition to, say, using
> local/internet sockets if it appears necessary.
> 
> So I'm asking - has someone already benchmarked this? Can you squeeze
> more data in one dbus invocation using protobufs without hitting
> buffer limit? How about serialization speed/size for complex objects?
> Code complexity implications?

I've just taken a quick look at the protobuf documentation (which doesn't seem 
to have any relation to Google, btw, except for being hosted on 
code.google.com).

It's just a marshalling format. It doesn't do anything else. It matches D-Bus 
marshalling, with a different format. From what I can see, anything you can 
encode in a protobuf you can encode in D-Bus too, but not the other way 
around. I don't see any way in protobuf to send variable-sized arrays, 
dictionaries, structures. I could even say I don't see a way of transferring 
Unicode strings -- there's only a byte-array type (which they call "string"), 
which you can use to transport those strings, as long as you agree on the 
encoding out-of-band.

Now, the protobuf encoding is shorter than D-Bus for the same payload. D-Bus 
is much more verbose, with each integer type occupying the same width, 
regardless of type. That also means strings are prefixed with a full 4 bytes of 
length.

D-Bus was designed for localhost communications, where bandwidth is not a 
problem. It was designed for parsing efficiency -- indeed, many items are 8-byte 
aligned inside the wire message so that they can be easily read on any 
architecture.

I'd say that, if you can, use D-Bus marshalling when using D-Bus. It'll be 
more efficient and also more compatible with existing implementations.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Qt Developer Days 2009 | Registration Now Open!
Munich, Germany: Oct 12 - 14     San Francisco, California: Nov 2 - 4
      http://qt.nokia.com/qtdevdays2009
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090920/0f77236d/attachment.pgp