[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Automatic bluetooth device initialization
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
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.