DBus for Generic Data Access Methods?

[Jim McDonald]

Marcel Holtmann wrote:

[...]

> You have to understand that the object path is not the unique element in
> the D-Bus architecture.
>   
Yep I understand this bit and that's why I think abstracting the paths 
works.  Say you have three separate items that provide address 
information on the paths:

/org/eds/contacts/addressbook
org/cleverdeveloper/querydirectoryservices/contacts
org/anotherdeveloper/myPIM/lookup

And you have written a GPS application that would like to obtain the 
home location of a known user and plot that location on a map.  It has 
to ask the three separate applications if they have the address of the 
user, and to do that it needs each application's object path.

   Now say a new developer looks at OpenMoko and says "Cool; I'll link 
this with my social networking site."  So off they go and writes an 
application that can look up a user on their social networking site, and 
sets up an object path of /com/socialsite/lookupperson.  The problem is 
that none of the existing applications will talk to it as they don't 
know about it, so it just doesn't work.  My point is that if there is a 
well-known object path, say /org/OpenMoko/contacts,  then everyone could 
use the same object path and as new applications are added that it gets 
added to the list and everything just works.

   Perhaps, as Kalle suggests, what is really needed is a service where 
we can map from the logical requirement for a service to a list of DBus 
names/servers/methods.  That would allow existing applications to work 
with their application-specific paths but still provide the benefits of 
the a simple way of finding all applications that provide a given function.

> Marcel
>   
Cheers,
Jim.