DBus for Generic Data Access Methods?

Marcel Holtmann marcel at holtmann.org
Mon Jan 29 23:03:48 CET 2007


Hi Jim,

> > > Moving the logical structure in to OpenMoko's domain is a Good Thing
> > > as it allows us to move at a faster pace than the other systems may be
> > > able to. 
> > >     
> > 
> > it is not. It doesn't give you any advantage since if you don't work
> > together with the eds-dbus people you are creating an incompatible
> > interface and that doesn't help you. It would be major drawback.
> >   
> Which is the point of a mapper or listening on two separate areas.
> But more to the point...

we are talking about embedded systems here. Every extra shim layer to
convert one data into another format costs you memory and performance.

> > Working closely with upstream projects is the only way to actually
> > create a nice standard. What you propose is actually what you complained
> > about in the first place. You need only one API that is common for all
> > application and not two.
> >   
> The problem then is that if you have to adhere to the EDS API then
> what does the guy who hates the limitations of EDS and wants to write
> his next-generation system do?  He's stuck with using the EDS DBus
> calls, even if they don't fit his needs, because that's all that the
> other applications listen to.

Again. This is open source. You can fix it.

> > Actually you need to look a little deeper into D-Bus first. I think your
> > understanding of object paths and interfaces lacks a little bit. I had
> > the same problems in the beginning, because it is not easy to understand
> > how D-Bus actually works and how you use it.
> > 
> > An object path is only a string. It has no real meaning and can be fully
> > dynamic. In the HAL case for example you only have one fixed object path
> > and that is for the manager interface. All other device related object
> > paths are discovered through the manager. The BlueZ interface follows
> > the same approach.
> >   
> Right but you have to know what to look for.  Because object paths are
> (near-enough) freeform strings there needs to be some logical
> structure for others to follow or else they won't be able to handle
> code in a generic fashion.  Unless I missed something, interfaces
> aren't going to help us as they are not used in the same way as
> interfaces within an OO paradigm.

The interfaces are a collection of method and signal prototypes that can
used on a specific object path.

And don't get my point here. You don't need to have any structure with
the object paths. You only need one central point to discover them and
in the worst case this can be done via introspection. Actually the
interfaces describe what you can do with an object path.

> This really comes down to the question of is there going to be a
> single logical layout for all DBus object paths that makes sense in
> the context of the 'phone (or personal data assistant or whatever view
> makes most sense) or if there is going to be a collection of these
> from each of the applications that are decided upon as forming the
> 'core' of OpenMoko.  I'm very strongly in the former camp, but then
> it's not my decision to make.

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.

Your nice hierarchy and using /org/openmoko is in general not needed at
and most implementation follow them only, because the D-Bus examples say
so. For example using /contacts as path would work as good as any other
path name. So the path name doesn't matter at all. It is only a string
that has to start with a "/".

The well known bus names have to be unique across all implementations,
but that's basically it.

Regards

Marcel






More information about the openmoko-devel mailing list