D-Bus usage

[Shawn Rutledge]

> > >  Maybe I don't know dbus well enough, but it seems to me that a process
> > > merely registers a session with dbus, not keeping a connection open.
> >
> > How do you think that works then?  I figured it's analogous to the
> > connection between an X program and the X display server: there is an
> > abstraction that looks like a connection but it could really be either
> > a socket or shared memory or maybe something else.
>
>  Between application and libdbus it could simply be a registered callback.

Yeah, they are linked, and running in one process.  But what about
between that process and the dbus daemon?  It has to be some kind of
connection.  Either the connection is held open or both sides must be
listening, because messages can go either direction, spontaneously,
right?  (But maybe the "connection" could also be other things like
shared memory or a pipe... I'm not sure.)

>  Maybe dbus could use some marshalling solution to connect the dbus transport
>  channel between hosts, so you won't need to add network tranparency to each
>  service/interface separately?

Maybe.

>  > >  Well not really, since a service could conform to multiple interfaces.
>  > > It enables applications to call a service, even if it doesn't know the
>  > > actual service, but only one of its interfaces.
>  >
>  > So if a service has registered a method with all possible names (the
>  > service name, the interface, the path and the method name) how many of
>  > those are necessary to uniquely identify the method, actually call it
>  > and get a response?
>
>  identifying and calling isn't the problem.

Well you were saying that all 4 names are not necessary to find a
method, right? so given that the method was registered with all 4
names, which ones are necessary in order for another process to call
it?  I figured it has to match all 4.  Or if some of them are empty
then maybe those don't have to be matched, but it depends on how the
method was registered, right?

>  It's more about finding out the
>  capabilities of the service you want to call.

I don't know anything yet about how to enumerate the possible
services/methods/whatever.  I will need to find out...

>  For instance, there is a caption() method on a KApplication interface, but
>  there could also be caption() methods on other interfaces (e.g. child
>  windows). The method signatures are the same, but the interface is different.
>
>  Also, when logging out, the session manager just has to enumerate all
>  KApplication interfaces and call quit() on them, without triggering quit()
>  methods on non-KApplication  quit() methods.

Are those possible?

(BTW how this came up for me... I can see that my Display Scheme
project could use dbus for at least a couple things, such as GPS data,
interfacing to Avahi, and maybe gsm.  So I decided to write a
general-purpose dbus "egg" for Chicken Scheme.  So now I have to learn
all the details of how to use libdbus to make that possible...  and
then I want to understand what it's good for and what it's not.)