DBus for Generic Data Access Methods?

[Marcel Holtmann]

Hi Richi,

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

the thing that is wrong with the interface. If any.

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

The D-Bus interface will already be that layer. So no extra layer on top
of it is needed.

And let me repeat this over and over again, we are talking about open
source. We can fix things if we later realize they were wrong or not
sufficient.

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

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.

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. An example for that would be that you are not going to
transfer a complete email (including attachments etc.) via D-Bus. It is
simply not designed that way. It is a message bus and you exchange
messages and not do data transfer.

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

What has that to do with anything. And I haven't even touched the area
of localization.

Regards

Marcel