DBus for Generic Data Access Methods?
Bryan Larsen
bryanlarsen at yahoo.com
Tue Jan 30 15:15:33 CET 2007
Jim McDonald wrote:
> 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 when we have that problem is the time to have that discussion.
Mickey has said that EDS does things the right way. The open source
world has been around the block re: contacts many times, and EDS likely
incorporates that painful knowledge.
Anybody writing code for OpenMoko will use EDS, because otherwise they
won't integrate in properly. But the code might come from a different
project; or the EDS interface may not be appropriate so this developer
may come up with a parallel but separate interface to get an initial
application out there ASAP. (release early, release often).
In the first situation, it's a simple patch to the application to get it
to be compliant. Much easier / cheaper than adding a new abstraction.
In the second situation, the original abstraction would have been wrong,
and we'd still have the same problem.
Either way, both are easy to fix in the open source world. Patch all
the apps involved, bump the dependency information and it's magically
fixed. OK, it's non-trivial, but it's better than abstraction done too
early. In my experience, any abstraction layer designed before there
are two competing implementations is always buggy, incomplete and
over-specified. Cf. internet (implementation-based) standards and ISO
(design by committee) standards.
Also Cf the linux kernel. When they realize that it's time to change
the internal API, they just change it. They may have to patch 100
drivers, but they've got the source to all of them. Contrast that with
the external API, which they cannot touch easily. We've got cruft in
that API, some of it more than 30 years old. In a lot of cases, it's
good cruft, the result of lots of experience. In other cases it isn't.
This doesn't mean it's all that much easier to change the internal
API; before it's done, all in-kernel users of that API must be changed
and verified; so it's not something that's done willy-nilly. But it is
possible, and it is done when it is advantageous.
I think I've gone off topic. I really don't know much about D-BUS, but
I really do get the impression that some people do not understand the
power of open source. I'm personally responsible for a couple of really
ugly API's / abstraction layers. At the time I thought they were a good
idea. (Then my stack will be super useful to all my users because it'll
be super flexible!) Luckily most of them were so horrible that they're
(mostly) dead, but hopefully somebody can learn from my painful experience.
Bryan
More information about the openmoko-devel
mailing list