DBus for Generic Data Access Methods?

Richi Plana myopenmoko at richip.dhs.org
Wed Jan 31 19:38:30 CET 2007

On Mon, 2007-01-29 at 23:03 +0100, Marcel Holtmann wrote:

> You do know that the object path is specific to the daemon that provides
> it anyway. The access to a method or signal of an interface is done via
> the unique bus name _and_ the object path.
> This means that daemon A can register /org/foo and daemon B can
> register /org/foo and both are different and independent, because daemon
> A and daemon B doesn't have the same unique bus name. You can even have
> a different set of interfaces on each of these two paths.

I think a nice analogy to how DBus works is the TCP/IP network as used
on the Internet. A process is like a server on the Internet and is
assigned a unique IP address (dealing with simplest case here; no NAT,
etc.) and fully qualified domain names (bus names) can be mapped to IP
addresses. For each service available on each machine, a well-known port
(DBus object path) is assigned. By convention, certain protocols (DBus
interfaces) are assigned to each well-known port (/etc/services gives a
good summary).

Carrying the DBus analogy forward, it is possible (though impractical)
on the Internet to ask for all servers that have their http port (port
80) open by contacting a directory server (non-existent) or even all
server-port combinations which support the http protocol, or the smtp
protocol, etc.

Hope this helps. Please correct any mistakes.

Going back on-topic, we don't need to create new protocols / interfaces
for every problem we find. Instead, collaborating with the bodies which
handle the interfaces we're having problems with is the better approach.

If the information an application needs are available from different
process with different interfaces (and which we've no control over. ie.
someone else's project) then maybe an extra layer might be called for.

By the way, is there a wiki set up that actually summarizes and distills
whatever is discussed on this list (regarding dbus interfaces for
various services on the OpenMoko) so that we don't go around in circles?

Richi Plana

More information about the openmoko-devel mailing list