|
|
| Daemon News Ezine | BSD News | BSD Mall | BSD Support Forum | BSD Advocacy | BSD Updates |
[...]
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 needed here.
thanks, max