Automatic bluetooth device initialization

[Panagiotis Astithas]

Maksim Yevmenkin wrote:
> 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.

The same holds for libbtctl of gnome-bluetooth.

I wouldn't dismiss an effort to standardize on a dbus API, though. I can 
see quite a few advantages in such an approach:

- dbus is already ported to FreeBSD and many other systems
- porting kde-bluetooth or gnome-bluetooth would essentially require a 
new (albeit slim) portability layer in order to minimize synchronization 
effort with the upstream sources
- the bluetooh subsystem speed requirements are not very high, as to 
prohibit a (hopefully efficient) portability layer
- it seems much more feasible to target the compatibility on a dbus API 
than to reach consensus on a posix-like API

Nevertheless, if you are confident that we can achieve standardization 
in a lower level, I'm definitely all for it.


Regards,
Panagiotis