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 _______________________________________________ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community