DBus for Generic Data Access Methods?
marcel at holtmann.org
Wed Jan 31 21:28:23 CET 2007
> > > 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)
and again. This is D-Bus and not something like C# or Java. You have to
define all constants for every language binding that you support. So
strings are much simpler and much more intuitive than numbers. Strings
also makes the resulting code more readable. I don't wanna look up
numbers or self-defined constants when reviewing code.
> > 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.
Be careful with using D-Bus the wrong way. You have to design your API
really carefully. The system or session bus has to dispatch the
messages. The amount of data in the message and number of messages is a
bottleneck. However in your case it has only be as fast as people can
type. And btw. a contact lookup would be a string parameter anyway.
More information about the community