DBus Extensions

[Thiago Macieira]

Ryan Lortie wrote:
>> That's what my conceived-but-not-implemented DCOP bridge would do for
>> complex messages.
>
>If your "complex messages" might be something that a wider range of
>people might like to send, please propose them to the list.  We're
>currently seeing a huge number of suggestions for additions to the DBus
>type system and everyone should probably be heard out on their ideas.
>Sending complex messages as a binary blob is unfortunate.

Ryan and I had a nice discussion on IRC about this kind of thing. I have 
to collect my thoughts and let the ideas mature.

But let me summarise a bit here:

DCOP and QDataStream:
QDataStream works as the "body" of the message. The types (signature) are 
sent in a separate portion of the DCOP message. Unlike D-Bus, the type 
system isn't fixed: it's just the C++ class names as strings. That means 
DCOP used to send very non-standard types, specific to each application.

That's the kind of "complex message" that I alluded to, above. That kind 
of message the bridge I conceived would be wholly unable to translate 
back into D-Bus types, because it can't demarshall the data in the 
QDataStream stream.

QDataStream was conceived to be a serialisation to disk, such that the 
same application will load it back. So it doesn't try to limit the types 
to well-known ones. But, unlike DValue, it doesn't try to use the data 
loaded from the file directly -- it wouldn't work with Qt classes 
anyways.

DValue:
Ryan explained quite a lot of the format and I find it very interesting. 
So interesting that it could be standardised for anything stored on disk.

At the same time, I am unsure about the value of the indexes it provides 
on a network stream like D-Bus. Quite simply because almost none of the 
bindings can make use of them.

New types and protocol extension:
I, for one, have no interest or need for any new types on D-Bus. The only 
that makes a bit of sense to me is an empty variant (variant carrying 
nothing). A maybe-type would be a distant second to me.

That said, however, I do have an interest in keeping the protocol 
backwards compatible whenever possible and also allow for future 
expansions without the pain we're seeing now. This is the part where I 
have to collect my ideas and write a better email explaining.

Food for thought: the idea is to detach the "meaning" of the types from 
the actual transport.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070811/f55cc597/attachment.pgp