DBus for Generic Data Access Methods?

[Marcel Holtmann]

Hi Kalle,

> > the question is still why. We have EDS. So no reason to invent another
> > interface for the same purpose. Don't try to over-complicate things.
> 
> I'm not saying that there should be any change to dbus as it is. I'm
> only advocating the 'well-known' part of this all.

nobody was talking about changes to D-Bus.

> I'm saying that it's counter intuitive to give a good library and
> platform, with no centralized format for these things, be they only
> strings. It'd be good to have some form in them, but that is not my
> point.
> 
> I'd like to see a library that collects them and from which I can use
> them and browse them. Atleast for the part that is well known and that
> does not change on every whim. I'm sure you are not against such a
> thing, and we are probably only misreading one another.
> 
> This lib may take form as a document, I'd be totally happy with that.
> Centralized document, a javadoc for openmoko developers that contains
> these things.
> 
> Or a header file. That'd be fine too.

Header files only work for C/C++. D-Bus also supports bindings for
Python, Perl etc.

> I'm not asking for far reaching changes for dbus.

And again. Nobody is going to change D-Bus. It works like it does, but
you need to understand how it works.

> > Actually D-Bus is a message bus with method calls and signals. So
> > basically it is only an API contract defined through the interfaces.
> 
> Yeah, that part of it is. I was referring to the next stage. Sorry if my
> message was a bit off-topic and hard to follow.
> 
> For example, openmoko devices might have many different services that
> provide networking. All those (bt, usb, wifi, gsm-data, gprs, edge...)
> work a little different and hypotetically accessing them via dbus leaves
> requirement of knowing how they are supposed to work (this one needs
> this credential..). As is the case with gps. Internal one might work
> differently from the one on the usb. Or the one on bt. -> different
> interfaces, different library, and all that.

I mentioned that before. You device task that you wanna execute on each
of these technologies and then the daemon is responsible to make that
work. I gave the example of SetMode() already.

> Therefore it'd require a lot of standardisation to create such a thing
> where these all would be just another device of type X. If this was
> possible then we *could* have a dbus address that has a program that
> could advertise these features. Like this:
> 
> /xx/yy/zz  NETWORKING_FEATURE
> /xx/yy/zzz GPS_FEATURE
> /zz/xx/yy  GPS_FEATURE
> 
> And programmers could then use just one of the GPS_FEATURES and not care
> about which actual device they are using. But, this is not a dbus issue.

You can have multiple interfaces per object path and you have
introspection if you want to. The introspection allows you to discover
object paths of a unique or well known bus name and its provided
interfaces.

Regards

Marcel