KDE adoption of D-Bus

[Havoc Pennington]

On Wed, 2006-02-15 at 17:39 -0800, Waldo Bastian wrote:
> I don't think bus forwarding to remote clients should be the default. It 
> breaks the assumption that all clients in a single DBUS session run on the 
> same host. E.g. if you start a help viewer via dbus you suddenly discover 
> that the host that runs your dbus session server doesn't have the help files 
> that belong to the application that runs on the remote server. I don't think 
> it's worth it trying to get all that right.
> 

Ah, I missed the detail that the DCOP file has HOSTNAME and not only
DISPLAY... (I'm guessing DCOP just punts on trying to canonicalize the
display name so localhost:0, foo.example.com:0, etc. will all come out
different even if they hypothetically aren't?)

So the DCOP scope is in principle per-(session,machine) pair, not 
per-session. Not sure what all the implications of that might be...
doesn't it break with stuff like a screensaver service, then if an app
on the remote session tries to activate the screensaver, you would get
two screensavers? i.e. it messes up the idea of session singletons.

This kind of stuff is why I avoided auto-launch so far; my working
principle was "make dbus-daemon work exactly analogous to the X server,
which people already understand" - then in any case where X remoting is
possible, dbus remoting should also be possible. And keeping the bus
daemon 1-1 with the X server means there aren't two definitions of
"session," still just the one.

I'm sort of assuming that if anyone genuinely cares about using X
remoting with modern apps then we'd eventually patch ssh to forward the
session bus address.

Whether we include a hostname or not, I'd still prefer to use X
properties instead of files, since file locking is not reliable on
network homedirs and you have to deal with cleaning up unused files.

I definitely agree with your overall principle that it's not worth
trying to get all this exactly right - to do so, we'd want a bunch of
separate buses, like the per-(user,machine) bus and the
per-(session,machine) bus and the per-(user,display) bus and this would
melt app programmers' minds and it wouldn't end up working right anyway
due to sheer complexity...

If DCOP has already tried the per-(session,machine) approach and it
works fine that's as good a basis to choose that way as any other I
guess.

> If you want that (and once dbus actually supports it) you can set 
> DBUS_SESSION_BUS_ADDRESS accordingly on the remote server after you have 
> connected to the remote server and before you start an application. But see 
> above.

It might be good to sort of decide how remote apps "should" be done, so
we could pursue any needed ssh or system default configuration changes,
app authors that care could code accordingly, and we could put a
recommendation in the man page.

Though really, I consider this a 0.5% case so I'm not going to argue
very hard about how it works... remoting an entire session is common
(thin client), remoting an app here and there is solidly in
sysadmin/hardcore-UNIX territory and as long as it works for the
terminal program and Emacs few people will notice it's broken...

Havoc