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