Introducing the concept of 'DBus domains'

[Kybernetik Kollektiv]

Thanks everyone for your replies!

@Ville
Collabora is, although it's a very interesting project, unfortunately,
not what I am looking for.

@Mohamed
I had a look at the local-export-daemon repository and I must confess
that I did not understand much of the code. Also I wasn't able to
compile it, It seems to be broken in multiple places. Like I have
already stated before, I really need (or better say: really want :-) )
'remote dbus' communication for my current project, so I started my
own thing. I want it to be as useful as possible for more people than
me, so I began an implementation utilizing the DBus-C-API. I failed at
this point, because I ran into serious problems with implementation
details and thus I decided to start again using C++/Qt. I have some
working code now, but there is still some work left, especially
cleaning up class interfaces, checking more function error codes and
writing test cases. So hopefully it will be useful for some other
people, even through it depends on Qt. I'd also like to add Avahi
support, but there is virtualy no documentation for its DBus API and I
don't know if it's worth the affort.
Of course I totally agree with you that it's a good idea to keep
everthing modular and have one peace of code do exactly one special
thing. I mean having DBus as a specialized local service and add extra
behavior by adding 'external' code is the correct approach. The
problem I see in this particular case is that it is now very expensive
in terms of CPU time to extend DBus to work over a network. Two points
of the design of DBus caused me the most headache: 1) An Object
connected to the DBus message bus is under no circumstances allowed to
spoof _all_ messages transported over the bus. 2) Each application can
only hold exactly one connection to the message bus at one time. I
mean, from the DBus designer's point of view, this is absolutely
alright, but building a 'dbus network router/proxy' with these
limitations makes things unnessary complex. The easiest way, in my
oppinion, would be to add an interface to the DBus message bus daemon
that external routing/proxy mechanisms can use to easily/fast access
the bus and then do the major work of connecting different 'dbus
domains' themselves.

Greetings!
Patrick