Discovery of per-session socket address

Maciej Katafiasz mnews22 at wp.pl
Tue Jul 13 21:32:32 PDT 2004


(There is to-be-modded copy of this message too, sent from wrong
account. D'oh. Please discard it)

Hi,
disclaimer first:
1) I searched gmane for a bit, didn't find anything relevant, although I
don't claim there isn't anything in archives. So point me there if I
missed some past discussion, I'll gladly RTFM :)
2) I _don't_ have CVS dbus, only Debian packages ATM, didn't have time
to set up things properly yet. I guess I'm going to be (rightfully)
kicked for that, oh well.

Few issues popped up, and I have two questions actually:
- is it possible to set expected address of dbus session daemon socket
from within python bindings? or is DBUS_BUS_ADDRESS the only way to do
so?
- wouldn't it be better to (at least when above envar isn't set, but
preferably always when not explicitly prohibited) connect to "well
known" /tmp/$username/dbus-session, instead of failing? That would much
increase level of Just Working(TM), without need for setting that for
each user separately

In general, I've come to very much dislike environmental vars for such
usage, since they are almost as inflexible as one can possibly imagine.
They are great for storing invariants (like username), but ASA there is
need for any change, they become incredible PITA. There is not only no
way to apply new value without restaring app, there isn't even way to
actually change them (as they propagate only down the process tree, and
on startup only)!. Of course, envars have their advantages (like utimate
portability, and great simplicity), but IMHO shouldn't be used for
denoting anything that can imaginably change over lifetime of session
and needs to propagate.

In particular case of DBUS, _any_ crash (highly undesirable event, of
course, but unfortunately happens in RL, and we should be robust enough
to handle it gracefully), or restart (say, on package upgrade, or
whatever) effectively invalidates _all_ previously started clients, and
forces full session restart. And as much as I want to kill whoever
decided to use envar for storing XIM when I happen to not be farsighted
enough to anticipate I'm gonna need to input Japanese 3 days after
starting my session, I'd absolutely hate to see DBUS vulnerable to, so
much enjoyed by our win32 friends, "Detected mouse movement, please
restart to update settings" effect (actually, in some areas win32 is
much better wrt to on-the-fly application, like IM can be started and
works instantly, and so can be many of syscall-intercepting hacks, but I
digress).

So, if there are reasons that make envar the only / best solution, well,
so be it, and I'll shut up. But if not, I'd very much like to discuss
that, and as much as possible avoid using envars.

Cheers,
Maciej

PS. I'm sorry for my overly verbose and digressive style of writing, I
really try, but can't help it ;).

-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 at wp.pl>
       http://mathrick.blog.pl
-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 at wp.pl>
       http://mathrick.blog.pl




More information about the dbus mailing list