DBus for Generic Data Access Methods?

[Knight Walker]

If I may butt in for a minute...

On Mon, Jan 29, 2007 at 09:07:26PM +0100, Marcel Holtmann wrote:
> 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.
 
> You don't subscribe to signals. The signals are broadcasted to the bus.
> However you can setup what signals should wake up your process.

I think by "subscribe" he means "decide which signals your program should
act on".  Like subscribing to particular news feed gets you all the data
for that feed, "subscribing" to a signal gets you all the data for that
particular signal.

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

-KW