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.
_______________________________________________
OpenMoko community mailing list
[email protected]
https://lists.openmoko.org/mailman/listinfo/community
