|
|
| Daemon News Ezine | BSD News | BSD Mall | BSD Support Forum | BSD Advocacy | BSD Updates |
Marcel,
while i appreciate your effort in this area, i'm skeptical that d-bus and/or whatever api will solve this problem. i think, instead of introducing yet another compatibility layer that sits on top of native api, everyone would be much better off if native api was the same. what would solve this problem, imo, is the standard (something like posix) that would define api etc.I don't really like D-Bus, but it will be the way to go for a general API for the desktop. It has multiple language bindings already and our goal is to make it totally generic (no BlueZ specific definitions).
perhaps, we are talking about different things here. i do not really understand what multiple language bindings have do with bluetooth device initialization and lower level api.
it very much possible that d-bus is very well suited for inter-application communications in kde/gnome/whatever desktop. after all, this is what it is being developed for. what i do not understand is why d-bus is being pushed all the way down and even suggested as replacement for hci? instead of creating numerous d-bus bluetooth applications that know how to work on particular system, why not just create one d-bus bluetooth application that uses common low level bluetooth api? what about not-kde/gnome/whatever applications (i.e. non-d-bus)? are those just out of luck?
i admit kde/gnome folks did a lot of work by integrating bluetooth, but their work can not be re-used :( i wish their work would be in a form of re-usable user space modules. i wish they would make it so anybody can just pick this or that module and re-use it. for example, if i want to run obex file server, i do not have to run kde/gnome/d-bus etc.
thanks, max