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