<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
&nbsp;&nbsp; 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.&nbsp; There are two reasons why I
believe this is key to development of a system like OpenMoko:<br>
<ul>
  <li>It allows developers to generate drop-in replacements for
existing functionality (don't like the existing contacts manager and
want to write your own?&nbsp; As long as you meet the interface contract
then no problems)</li>
  <li>It allows applications to obtain data (and also update it, of
course) without needing to know much about the external program(s) out
there.&nbsp; More importantly, it allows applications to obtain data from
arbitrary providers<br>
  </li>
</ul>
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.&nbsp; So I had to load up my contacts
manager, copy Fred's postcode, and then go back to TomTom to paste that
in.&nbsp; 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.&nbsp; Ugly
ugly ugly.<br>
<br>
&nbsp;&nbsp; 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.&nbsp; Combining well-known
paths and methods with publish/subscribe starts to become very
interesting.&nbsp; For example, in your navigation app you ask for Fred's
information.&nbsp; This sends out a message to all address-capable
applications.&nbsp; Unfortunately although you have Fred's contact info on
your 'phone you don't have his address.&nbsp; 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.<br>
<br>
&nbsp;&nbsp; So what's special about the above example?&nbsp; 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.&nbsp; Separately, someone else writes the app that just
queries directory services for information given a key (email address,
for example).&nbsp; And although these two apps don't necessarily even know
about each other, or the navigation app, they all play happily together.<br>
<br>
&nbsp;&nbsp; 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.&nbsp; Are there any moves afoot to look at setting up such
information?<br>
<br>
Cheers,<br>
Jim.<br>
</body>
</html>