DBus for Generic Data Access Methods?
Jim McDonald
Jim at mcdee.net
Mon Jan 29 18:20:03 CET 2007
Hi,
I've been reading about the idea of generic access to a data store
for configuration information but was wondering if there are plans to
have generic access to actual data. There are two reasons why I believe
this is key to development of a system like OpenMoko:
* It allows developers to generate drop-in replacements for existing
functionality (don't like the existing contacts manager and want
to write your own? As long as you meet the interface contract
then no problems)
* It allows applications to obtain data (and also update it, of
course) without needing to know much about the external program(s)
out there. More importantly, it allows applications to obtain
data from arbitrary providers
Picking TomTom as the last example where the lack of the above annoyed
me, when setting up a route there was no way of saying "I want to go to
Fred's house" even though Fred's information was sitting there in the
contact DB of my 'smart'phone. So I had to load up my contacts manager,
copy Fred's postcode, and then go back to TomTom to paste that in. Then
of course I had to type in the house number, which I also didn't have,
so ended up having to jot it down on a bit of paper. Ugly ugly ugly.
The obvious communications mechanism for this is DBus, and in this
environment the interface contract would be a list of methods and
signals to implement on a given object path. Combining well-known paths
and methods with publish/subscribe starts to become very interesting.
For example, in your navigation app you ask for Fred's information.
This sends out a message to all address-capable applications.
Unfortunately although you have Fred's contact info on your 'phone you
don't have his address. Fortunately one of the apps listening to the
message is designed to hit a number of well-known directory services out
on the 'net and it finds the info you are looking for from one of those
and so you get the data you were after.
So what's special about the above example? It's modular: the person
who owns/writes the main contacts manager app doesn't know or care about
talking to directory services and focuses on generating the best app
they can. Separately, someone else writes the app that just queries
directory services for information given a key (email address, for
example). And although these two apps don't necessarily even know about
each other, or the navigation app, they all play happily together.
Anyway, I guess that my point is if there is some attempt to make
this work then the key things that needs to be sorted out is a set of
well-known object paths, methods and signals so that this type of thing
would work. Are there any moves afoot to look at setting up such
information?
Cheers,
Jim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-devel/attachments/20070129/f6c86935/attachment.html
More information about the openmoko-devel
mailing list