Abstraction Layers (was: DBus for Generic Data Access Methods?)

Michael 'Mickey' Lauer mickey at openmoko.org
Tue Jan 30 15:25:21 CET 2007

Bryan Larsen wrote:
> 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 have adjusted the 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.

I agree. Since getting abstraction layers right is so hard, you
probably won't be able to make it unless you're a über-genius
engineer. In closed-source systems, you have no choice but leave the
APIs and deprecate them, if you add new ones. Open Source systems have
better options. I hope that -- at least during the early OpenMoko days,
when the framework isn't widely spread -- we can just fix mistakes in the APIs
even if that means, removing or renaming functions -- or even changing
their semantics.

- Michael Lauer <mickey at openmoko.org>                   http://openmoko.org/
Software for the worlds' first truly open Free Software mobile phone

More information about the openmoko-devel mailing list