DBus for Generic Data Access Methods?
Lars Hallberg
lah at micropp.se
Mon Jan 29 23:40:58 CET 2007
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
More information about the openmoko-devel
mailing list