DBus for Generic Data Access Methods?
marcel at holtmann.org
Mon Jan 29 22:42:05 CET 2007
> > I have no idea what you are meaning with this. The D-Bus object path is
> > only a name and it actually doesn't matter what it is. The object path
> > from the dataserver is as fine as any other path.
> 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.
> > Actually that is the total wrong approach. You first think about
> > possible applications and then analyze their needs. The application
> > needs are essential to design a good D-Bus based API. Think of tasks
> > that you wanna fulfill with your application and then you have to design
> > an interface with methods and corresponding signals for that task.
> Except that your approach only gets us the infrastructure needed for
> current applications. This isn't a bad idea, since we don't want to be
> lugging around a bunch of extra APIs that no one is using. It means that
> when in six months, someone (e.g. me) comes up with a new feature, I may
> have to hack and slash the existing API to shoehorn it in. That shouldn't
> be a problem if the API is flexible enough, but if we focus too closely on
> the task needs as they are currently, we'll end up with a hodge-podge.
First of all. This is open source and you can change the code if it is
not sufficient for your needs. Second of all D-Bus supports multiple
interfaces per path and you can use introspection to discover them. So
if you need a new function than you extend a current interface or
implement a completely new interface for that path.
A flexible API ends up in properties interface (and D-Bus has already a
specification for that). This is not what you want. And once you start
writing all these applications you will actually see what I mean.
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")
What you really wanna do is to make it as easy for the application as
possible. Since the application developer shouldn't have to care about
the technology at all. So first you wanna abstract from the technology
and define standard terms. The mode setting example above would have
been looked like this when using technology terms (abstract language):
The main difference between the Neo1973/OpenMoko, the Nokia N800/Maemo
and others is the UI and the actual applications. All the hardware
related daemons and functions can be shared. So every additional code
you put into the applications that can be shared across hardware and
across platforms is wrongly placed there.
More information about the openmoko-devel