Automatic bluetooth device initialization

[Maksim Yevmenkin]

Paul,

>> fine. if you could please tell us a little bit more and explain
>> what is wrong with the current way of doing things in linux and/or
>> freebsd.
> 
> don't get me wrong, there isn't anything wrong with the current state
>  of bluetooth configuration utilities. If you've spent some time 
> reading the freebsd handbook or some unofficial bluez tutorials and 
> you're accustomed to the command line (like most of the people on
> this list, I assume) then you're just set.. ..but if you take into
> account the regular desktop user (like how linux and freebsd are
> trying to do right now) you see the need for something more intuitive
> and immediate than the 'current way of doing things', this basically
> involves some sort of user interface, at the very least. Even on this

i though we are talking about bluetooth device _initialization_. right 
now, in freebsd, user does not have to do anything except loading the 
drivers and plugging the device. all configuration parameters are in one 
file and documented. adjusting configuration for bluetooth devices in 
freebsd is not that much different from putting stuff into /etc/rc.conf 
etc.

i agree with you, there is no gnome/kde/whatever gui applet that knows 
about bluetooth in freebsd. i also admit that there are no gui based 
bluetooth tools in freebsd. however, this, in my opinion, has nothing to 
do with bluetooth devices initialization.

> mailing list, little time ago, there was a request about porting the
> excellent kde bluetooth framework to freebsd, but, as you noted, in
> it's current form kdebluetooth has very deep roots in bluez, and it
> also has deep roots in KDE, so even adapting to another desktop 
> manager would be difficult. To solve such (not uncommon) problems,
> the dbus system[¹] is being developed, dbus is getting very popular
> (maybe too much) and it provides a simple and secure messaging system
> to let different programs talk to one another, in our example, let
> one program be the bluetooth daemon, it provides a well-known
> interface and hides platform-specific implementation details, on the
> other side we have the other programs, which are just frontends (with
> a Qt/Gtk/textual interface, it doesn't matter) and can run on every
> operating system where the aforementioned interface is available, I
> think something like this wouldn't hurt to any "desktop-unix"
> operating system.

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.

in the very beginning, i asked linux bluez folks if they are willing to 
release their user space code under dual (gpl/bsd) license. someone 
immediately shoot me down with the statement that bluez code is gpl and 
it will remain so forever. i admit, it was a very weak attempt and i did 
not push it any further. instead, i choose to write my own code under 
bsd license so it can be included into freebsd.

i took a very quick look at kde-bluetooth sources and i could not find 
anything that would suggest that kde-bluetooth is trying to work on non 
linux-bluez systems. it seems like all that needs to be done is to teach 
libkbluetooth about other non linux-bluez systems.

thanks,
max