Automatic bluetooth device initialization

Maksim Yevmenkin maksim.yevmenkin at savvis.net
Tue Dec 6 00:58:50 GMT 2005


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


More information about the freebsd-bluetooth mailing list