DBus for Generic Data Access Methods?

[Lars Hallberg]

Marcel Holtmann skrev:
> Hi Jim
>  
>   
>> Moving the logical structure in to OpenMoko's domain is a Good Thing
>> as it allows us to move at a faster pace than the other systems may be
>> able to. 
>>     
>
> it is not. It doesn't give you any advantage since if you don't work
> together with the eds-dbus people you are creating an incompatible
> interface and that doesn't help you. It would be major drawback.
>   
True, but still I think it's better to standardize on interfaces, not 
implementation. Now there is only one implementation of eds and eds 
looks like the on right contact management interface. That's probably 
the ideal situation. But it is os, and next year it might (lets hope 
not) have forked. And people want to use different eds, with different 
path. And they compatible enough for the basic parts to work with both 
(maybe completely compatible but defer in implementation).

At least it should be a central 'openmoko' place pointing to the 
implementation in use. IMHO, basically any part should be replaceable 
and with minimal  effect on interoperability if the replacement is 
compatible. Howe ever little us for that we can see right now.

Now I don't know D-Bus enough to know if it 'solve' this on its own.  
just a possibility for system admin/tools to set symlinks in the D-buss 
address space might be enough.

But, besides implementations, there is also extension.

Contacts is so central to a phone, so it should be a central place 
listing add-on services. Pointing to respective interface. And have a 
minimal common interface. Like:

find all matches for a string, return list of id and 'dispaly' name.
get a 'compact' set of data for a id in a list of key value par.
get a 'full' set of data for a id in a list of key value par.
get a list of all used keys.
get the value of one key for one id.

setting may be saved for the service own api only. Stuff that don't know 
the service should probably not set values. But reading can still be 
useful. An app might not know the service, or what value mens what. But 
the user might. And if the user can chose what service to ask and what 
value to show a lot is gained.

People with special interest can get special info showed with the 
contact info. Info we can't predict and from sources we don't know, ie: 
golf or other sport stats.

Helping people finding peers with common interest they else would have 
missed is a big goal for communication technology.

/LaH