DBus for Generic Data Access Methods?

[Richi Plana]

On Tue, 2007-01-30 at 06:51 +0100, Marcel Holtmann wrote:
> > Personally I would prefer
> > 
> > bluetooth.SetMode(bluetooth.Mode.CONNECTABLE) # or whatever the
> > consensus is for constants
> 
> Except that D-Bus is not C# or Java. It is an object oriented approach
> for an API, but it is not an object oriented programming language.
> 
> > 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).
> 
> We have UTF-8 and so that is no big deal. And even 7-bit ASCII is a good
> common sense when it comes to string identifiers.
> 
> The problem with the common known constant is that you actually have to
> known it. Ask yourself what you wanna do when you type in a Python
> command line to change the mode of a device. Lookup a really long table
> with numbers of simply expect SetMode("off") to work.

With regards to interface design, I'm sorry, but I'm going to have to be
obstinate with this approach. If a given option takes a *finite*,
reasonably *predictable* and relatively *static* set of choices, I would
recommend using numeric constants rather than strings. First of all, the
problem of remembering these numbers shouldn't be the programmer's but
the document system the user is working with (and which is hopefully
tied well to the development environment). Why waste CPU cycles to
decode differentiate between "on" and "off" when numbers are easier?

Second, typing errors won't be caught when parameters are passed as
strings. It's also harder for the development environment to assist
programmers when parameters are in freeform text.

As for the localization issue mentioned above, I would rather have the
object understand common numbers and have the programmers use localized
identifiers that are translated by the compilers / interpreters to their
numeric equivalents rather than have the underlying object system (or
even the object itself) do the translation.

Even if I didn't have a smart development environment to help me, I
would still prefer to do SetMode(Mode.OFF)

> The advantage of speed is not that important. You don't have that many
> operation at one time any. And if you do than D-Bus is the wrong
> approach.

It's certainly not inconceivable for valid messages to have several
options passed to it and for the method to be called a multiple number
of times in a short time frame. People have already been talking about
using contact lookups to tie in with the IME (input method editor). IMEs
are very sensitive to speed, specially on low-powered devices like
cellphones. In those cases, every millisecond counts.
--

Richi