Introducing the concept of 'DBus domains'

[Kybernetik Kollektiv]

Hello everyone!

This is my first posting on your list so I think I should introduce
myself shortly at first. My name is Patrick, I am a hobbyist Qt/KDE
application developer.

I was looking for an IPC mechanism for my desktop applications that
would easily integrate with the signals and slot formalism of Qt. Of
course DBus fits my needs perfectly. The problem is, that I would also
really like to use DBus for something that it is not intended for:
communication between applications which reside in different desktop
sessions or even on different machines in a network. I began thinking
about a custom routing/proxy mechanism when I realized that the
current DBus protocol could be extended easily without breaking
compatibility. My idea is to introduce a new concept of 'DBus
domains'.

Each DBus message bus daemon must have an identifier, let's say an
UINT32. I'll call it 'domain id' for now. It has to be unique within
each operating system instance and within a network of operating
system instances which applications shall be able to communicate
through DBus domains. So the domain id would be a static configuration
parameter in every session.conf and system.conf.

The message format could be extended by adding two defintions to the
header fields:
1) conventional name 'destination domain id', decimal code '9', type
'UINT32', required in 'optinal
2) conventional name 'sender domain id', decimal code '10', type
'UINT32', required in 'optinal

org.freedesktop.DBus.Peer would have to be extended with an method
'i_know_domains()' through which a connected object can tell the
message bus daemon that it is able to understand the extended header
fields and thus is capable to communication beyond the boundaries of
its own domain.

When the object has not called i_know_domains (because it doesn't know
about them) than it will of corse never specify any domain ids in the
header of its messages. So in this case the message bus daemon must
not deliver messages from this object to objects in different domains
and it must not deliver messages from different domains to this
object.

If an object has called i_know_domains() then there are three possible
per message behaviors for the sending object:
1) The object attaches no destination domain id to a message. This
causes the daemon to deliver the message into all connected domains.
2) The object attaches a destination domain id (its own domain id or a
foreign one) to a message. This causes the daemon to deliver the
message only to the specified domain.

The message bus daemon would have to be extended with a domain routing
function. Routing between domains within the same operating system
context could use unix domain sockets and incorporate authentication
on the basis of system users and groups. Routing between domains in
different operating system contexts could be done via TCP sockets 1)
without any security (if the user's environment allows this) or 2) via
TCP sockets tunneled e.g. through TLS/SSL, encrypted and authorized
with certificates. As I see it, this second option does not have to be
build into DBus itself, instead securing out of operation system
communications can be left to the system administrators.

So, that's what I think and I'm looking forward for some feedback from
the experts :-)

Patrick

PS.: Sorry for my bad English!