DBus for Generic Data Access Methods?

[Richi Plana]

On Mon, 2007-01-29 at 22:42 +0100, Marcel Holtmann wrote:

> > Correct, but I think what Mickey is after is that the client programs just
> > ask for "contacts" and the translation layer checks both
> > '/org/openmoko/contacts' and '/org/gnome/evolution/dataserver/addressbook'
> > and anywhere else contacts or an addressbook may be.  Personally I think
> > this is a decent idea, as I've already had ideas for extra information
> > that could be housed in each contact, but I don't know how extensible
> > EDS is in this regard.
> 
> another totally useless shim layer. Not a good idea. Fix the current
> interface if it is not sufficient.

What example of a fix would you suggest?

I don't mind layers. Layers is a good thing in many cases since it
brings some logic to low-level interfaces, effectively making them
high-level calls. If there's a logical need for a shim layer, then it's
not useless. There might be better ways of doing it, but "better" has to
be qualified. That means a comparison of the pros and cons of various
approaches.

> Just a small reminder for people only thinking for one language. The
> D-Bus is accessible from various languages like C, Python, Perl, Mono,
> Haskell etc. While an enum with constants is great in C, it is not that
> much fun if you use the Python interpreter from the command line. Let me
> give you an example. What do you prefer:
> 
> bluetooth.SetMode(0x01)  or  bluetooth.SetMode("connectable")

Personally I would prefer

bluetooth.SetMode(bluetooth.Mode.CONNECTABLE) # or whatever the
consensus is for constants

First of all, there's that (granted minor) advantage of speed since
numeric comparisons are faster than string comparisons. In cellphones
and other low-powered devices, these things add up. But another
advantage (and one most people might not care about) is that it's easier
to make the API cross-language (human) when there's a common numeric
value which binds concepts (ie. it's conceivable even if unlikely that
someone might create an API with identifiers written in, say, Chinese).

Granted it's easier to manually play around with settings (a'la
gconf-editor) where the human doesn't have to convert to numeric values
and can instead use strings, I've always been of the opinion that
utility programs (GUI and text) should be smarter and have the programs
do the conversion and presentation (ie. text-completion in text-based
utilities and drop-down lists in GUIs).
--

Richi