DBus Extensions

[Avery Pennarun]

Just my two cents: if the protocol is *capable* of carrying what you
need to carry, then extending it is probably not a great idea for
compatibility reasons.

What people are really talking about here is extending the semantics.
For example, a nullable int is really just an int with a nullable
boolean attached; the protocol can already handle that just fine.  If
you want to support nullable ints, it should be added at the
language-mapping layer, not the protocol layer.

Incidentally, the project I'm working on involves sending the results
of SQL queries over the bus.  Any of my values could be nullable, but
it's quite painless to simply stick all the null flags into another
part of the message and ship it along.  We have to map these into
language types by hand for now, but the code for that only has to be
written once, which isn't too bad really.  I much prefer
assembling/parsing messages to quasi-magical RPC-like stuff.

If you want to talk about protocol extensions, what I'd actually find
useful is a portable bitarray datatype.  If I'm shipping a huge dbus
message with 100 rows of 10 columns, with each cell individually
nullable, I have 1000 dbus_bool_t's to send.  Having each one of those
suck up 32 bits on the bus is kind of silly.  Of course I can manually
encode the bits into array(dbus_int64_t) or something, but doing that
portably in every possible language is a little tedious.

Have fun,

Avery


On 16/08/07, Havoc Pennington <hp at redhat.com> wrote:
> Hi,
>
> I wonder if we need a concept of *both* intersection and union -
> sometimes people want to work with all the common languages, and
> sometimes they want to be able to round trip anything they can express
> in their language of choice.
>
> Though whether this means "there is some kind of flag in the protocol or
> introspection data" or "the protocol has the union of interesting type
> systems, and you should stay away from certain stuff by convention most
> of the time" I don't know.
>
> This "both" idea sets off some alarm bells for me, to be honest - it's
> just complicated and is one more thing to think about when people
> clearly find dbus too complex already. But, thought I'd mention it.
>
> Havoc
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>