DBus for Generic Data Access Methods?
Jim at mcdee.net
Mon Jan 29 22:05:35 CET 2007
Knight replied pretty much as I would have but a couple of additional
Knight Walker wrote:
> On Mon, Jan 29, 2007 at 09:07:26PM +0100, Marcel Holtmann wrote:
>> 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
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openmoko-devel