Question on C code - any programmatic way ofsettingDBUS_BUS_SESSION address?

Andrejus Chaliapinas a.chaliapinas at infosana.com
Wed Apr 23 10:07:04 PDT 2008


> > Well, my question was exactly related to that. Why do I need to deal
> with
> > some internals (dbus_connection_open, dbus_bus_register, etc.) instead
> of
> > having dbus_bus_get_private_by_address, which will do that all for me?
> 
> Because that is the API for connecting to non-standard buses.  My guess
> is you application is no longer connecting to a "session bus" in the
> dbus sense of the term, so why are you overloading it?  

I'll tell if that is correct for sure when I'll know more about DBus
possibilities/restrictions. So far as I understand we could have possible
pool (on system level) of private dbus sessions. Probably it's not that good
if each of them could have their own registered parties instead of having
one tree of them over just one user session bus. But thankfully it's
possible.

> The public API
> is two calls for connecting to non-standard buses as opposed to one call
> for well known buses (plus whatever code you would write to overload
> session bus).  

If that is described in some DBbus API - then it's enough for me, but I've
looked through code and there are some bus locking as well as ensure bus
data calls. Of course I could mimic all of that. Just thought that more
centralized approach inside API would be better for others.

> We aren't going to add the API because that just bloats
> the library.  

No problems while source code is available for particular part copy/paste.

> I'm not really sure what you want to do.  Can you explain
> further?  If you are looking to inject a session bus into your session's
> environment (as opposed to just your program's environment) that can't
> be done because environments are inherited from their parents.  Think of
> the env variable as an implementation detail.  In the future we might
> have a new system.  Mac OSX uses another method (or at least there are
> patches for it) since env can't be propagated to the session in a
> dynamic way.
>

In my environment I need to have several local user's originated dbus
sessions and ability to switch between them just via simple address passing
to some function in my code. If they all sit under one common system dbus
registration meta-tree and could be enumerated in that way - then probably I
don't need that address passing functionality at all.

Thanks a lot for your comments.

Andrejus



More information about the dbus mailing list