DBus for Generic Data Access Methods?

Marcel Holtmann marcel at holtmann.org
Mon Jan 29 22:23:59 CET 2007

Hi Jim
> > > I have no idea what you are meaning with this. The D-Bus object path is
> > > only a name and it actually doesn't matter what it is. The object path
> > > from the dataserver is as fine as any other path.
> > >     
> > 
> > Correct, but I think what Mickey is after is that the client programs just
> > ask for "contacts" and the translation layer checks both
> > '/org/openmoko/contacts' and '/org/gnome/evolution/dataserver/addressbook'
> > and anywhere else contacts or an addressbook may be.  Personally I think
> > this is a decent idea, as I've already had ideas for extra information
> > that could be housed in each contact, but I don't know how extensible
> > EDS is in this regard.
> >   
> 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.

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.

> > > Actually that is the total wrong approach. You first think about
> > > possible applications and then analyze their needs. The application
> > > needs are essential to design a good D-Bus based API. Think of tasks
> > > that you wanna fulfill with your application and then you have to design
> > > an interface with methods and corresponding signals for that task.
> > >     
> > 
> > Except that your approach only gets us the infrastructure needed for
> > current applications.  This isn't a bad idea, since we don't want to be
> > lugging around a bunch of extra APIs that no one is using.  It means that
> > when in six months, someone (e.g. me) comes up with a new feature, I may
> > have to hack and slash the existing API to shoehorn it in.  That shouldn't
> > be a problem if the API is flexible enough, but if we focus too closely on
> > the task needs as they are currently, we'll end up with a hodge-podge.
> >   
> Yep using a previous example if someone started from the single
> application level then they would send
> an /org/cleverdeveloper/myapplication/setringervolume path, because
> there is no structure in to which to fit their signal.  The result is
> that the next developer, who wants to write an application that shows
> all of the environmental information that the 'phone is gathering, now
> has to keep track of every developer and their applications to ensure
> that they are gathering from all of the possible places where the
> information may come from.  Alternatively, if there is a structure
> that says that all environmental stuff goes in
> to /opt/openmoko/environment then our developer that wants to show the
> environmental information just subscribes
> to /opt/openmoko/environment/* and happiness ensues.
> It won't be too hard to sketch out a rough setup for this stuff,
> starting with the two broad areas of hardware and applications and
> moving out from there.  It looks like MicroHal is pretty close to what
> we need and perhaps we don't abstract from that because of the fact
> that it is already pretty generic, but the application side will
> probably take a fair bit more work as we want to avoid thinking about
> applications and more about data provision and service.

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.



More information about the openmoko-devel mailing list