Hi,

Csillag Kristof wrote:
> Should I try to configure a bridge between the two D-Buses?
> (Does D-bus support this already?)
> 

There's no built-in support in dbus for this kind of scenario... to be 
honest I'm not sure how it should work.

> Can I make this work somehow?
> 

My guess is that you can't make it work without modifying the software 
packages (one or more of BlueZ, the apps, and/or dbus).

The hard part is to figure out *how* the software should be modified - 
not something I could tell you offhand ;-) seems like a pretty hard problem.

A quick thought is that the user's session bus daemon should link the 
apps on the different machines (client/server), assuming you have 
managed to forward DBUS_SESSION_BUS_ADDRESS so that everything in the 
session (using the same X display) is on the same dbus session bus (as 
it should be).

You could then have some stuff on the session bus running on the server, 
and some running on the client, with apps able to access both. Moreover, 
dbus provides a "machine ID" feature, which you could use such that each 
app or daemon on the session bus could figure out which machine it's on 
and communicate that to other apps.

I don't know how BlueZ is architected. If it involves apps talking to 
the system daemon directly, then apps really could only use Bluetooth on 
the same machine the app is running on.

But I can imagine architecting BlueZ in such a way that a 
per-(session,machine)-pair daemon was started for each machine involved 
in the session, which then bridged to the systemwide functionality for 
each machine, or something.

Probably a solution here should consider not only Bluetooth but also 
audio devices and so forth.

David Zeuthen could already have a plan for this, worth asking.

Anyway, I doubt it works out of the box already without hacking on the 
software, but I could always be surprised ;-)

Havoc

_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus