DBus for Generic Data Access Methods?
marcel at holtmann.org
Tue Jan 30 00:49:38 CET 2007
> >> 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).
the D-Bus interface only provides an API contract. You can replace the
underlying storage format or application at any time. That is the whole
point behind D-Bus. You don't link against any specific library except
the D-Bus library itself (or bindings in case of high level languages)
and then communicate over D-Bus.
If the implementation is EDS or if it uses Berkley DB or SQLite or if it
is anything else is longer important for the application as long as the
implementation fulfills the API contract.
And again, this is open source. If something is broken or not sufficient
then fix it.
More information about the openmoko-devel