DBus for Generic Data Access Methods?

[Richi Plana]

On Wed, 2007-01-31 at 21:28 +0100, Marcel Holtmann wrote:

> 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.

Yes, and that is something I don't mind living with. How often would you
have to do it, anyway? It would have to be implemented once in some
high-level API once for each language and only updated whenever changes
are made to the semantics. In the meantime, programmers could benefit
from development environments which take documentation or, at least,
code-completion into account. 

I know that D-Bus is not an object modeling system (even though it
certainly has concepts similar to it). Language-binding would have been
much simpler if D-Bus were indeed some networked object model, but since
it isn't, that shouldn't mean we should forget the elegance that the
object approach (for which D-Bus takes many of its features) brings.

Who knows? Eventually D-Bus might evolve so that constants values can be
embedded with their labels in the interface definitions, and stub
generators for high-level languages like Java can take advantage of it.

> 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.

First of all, that was just an example (albeit a poor one). It's true
that the system's response time only has to be fast enough so that the
human operator doesn't notice it, but a subsystem developer should also
be aware that their system isn't everything that's going to run in the
whole scheme. A contacts lookup could just be one thing that an IME
might look into, but it could also be a dictionary, a recently used word
list, etc. Yes, these lookups usually have strings as parameters, but
they could potentially have options, as well. The last time I did IME
work, options such as which backends to look into, case-sensitivity,
etc. were options that could be passed either as numeric values or
strings.
--

Richi Plana