DBus for Generic Data Access Methods?

[Bryan Larsen]

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