[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.
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
so what? how about other things like sysv message queues, fifo's, unix
sockets, and, what the hell, solaris doors. i'm sure other folks can
also name a few. those can be used just as easily to implement any
message passing protocol.
- 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
have you even looked at what it takes to port libkbluetooth onto
freebsd? it seems that majority of the work can be done in one
afternoon. all you need is to change headers, some structure names,
constants and things like this. i bet all it takes is a couple of .h
files with lots of #ifdef's. another few days is to hook up this to gnu
autoconf. i have ported few tools from bluez to freebsd. its not hard at
all. for example, hcidump from ports _is_ ported from bluez. i'm 100%
sure adding dbus or whatever layer is much _more_ work.
the main problem here, imo, is to get kde-bluetooth folks (and others
gnu developers) to recognize the fact that there are other systems
besides linux. for example, gammu/gnoki port is quite capable to use
bluetooth on freebsd. my point is that just because dbus exists it does
not mean everybody have to use it for everything. i'm sure there are
projects where it can be quite useful, but, i think, in this case its
too much work for too little gain. kde/gnome already have enough bloat,
and, quite frankly, i do not understand why would someone want more
bloat. personally, i can not run kde/gnome on my laptop, because
otherwise i can not do anything else.
- the bluetooh subsystem speed requirements are not very high, as to
prohibit a (hopefully efficient) portability layer
still does not mean you have to add the overhead.
- it seems much more feasible to target the compatibility on a dbus API
than to reach consensus on a posix-like API
i doubt it. whatever api is being invented right now is being invented
on/for linux/bluez. in fact, i'm quite surprised (in a good way) that
Paul sent this email and told us about his work. i really appreciate his
effort in this area. i'm just suggesting that, perhaps, dbus does not
suite very well in this case. and, perhaps, simple set of user-space
wrapper libraries released under both gnu and bsd license is all that is