Introducing the concept of 'DBus domains'

[Kybernetik Kollektiv]

Thanks for your reply!

The main point I see (and that is my motivation) is the possibility of
adding benefit to existing applications without changing their source
codes. The mechanism I described above could add remote connectivity
to all applications that use dbus, but all the neccessary changes were
confined to the underlying tool kits (e.g. Qt-Dbus), so it would be
sufficient to simply recompile them with new tool kit versions.
Application developers would no longer have to somehow reinvent the
wheel again and again to add network connectivity to their products.
For example: I have a tiny linux computer connected to my hifi system.
It runs KDE and Amarok music player. Amarok exposes an dbus interface
to all the other desktop programs, but it what would be really nice if
I could control it from a linux smartphone. Another use case is
synchronization of PIM data between e.g. a smartphone and a laptop or
even within an office with, let's say 20 desktop machines. I think
DBus is the best choice for tasks like these, because the applications
already support this kind of interconnection, but it is only limited
by the capabilities of the DBus-daemon.

As I had a deeper look at the DBus sources, I must admit that adding
new behavior would cause a great amount of work and very good
knowledge about the internals of DBus are indispensable.

Because I need DBus network connectivity for my current project, I
have started implementing a client/server application that functions
as a bridge between DBus sessions busses. I'm not that happy with this
approach (among other things), because it causes round trips within
the connected DBus'ses which were evitable if the routing would be
done by the DBus daemon itself. However, the design and implementation
are straightforward and things should be working within the next few
days, depending on my spare time :-)

Patrick


2010/7/4 Havoc Pennington <hp at pobox.com>:
> Hi,
>
> For multi-system sort of applications, there are a boatload of
> projects designed for that:
> http://en.wikipedia.org/wiki/Message_queue
>
> I think the first question would be, what are your use cases where
> dbus is better than those things, and who would be maintaining dbus
> for this kind of application. Surely it's a major project to start
> down this road.
>
> A possible use-case (unmaintained/defunct) is embodied in
> http://git.gnome.org/browse/local-export-daemon/ which is just a
> little custom daemon that advertises a network service with Avahi, and
> speaks dbus protocol. Apps can talk to it via the session bus to
> export stuff, but it is distinct from the session bus.
>
> Anyway it seems quite dangerous to start trying to hammer every IPC
> nail with dbus. Sticking to "desktop related stuff" seems sensible...
>
> Havoc
>