DBus for Generic Data Access Methods?

[Kalle Kärkkäinen]

Hi marcel,

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

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.

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

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

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.

--
Kalle.