Date: Wed, 07 Dec 2005 03:52:51 +0100 From: "Ronald Klop" <ronald-freebsd8@klop.yi.org> To: freebsd-bluetooth@freebsd.org Subject: Re: Automatic bluetooth device initialization Message-ID: <op.s1d7mdaa8527sy@localhost> In-Reply-To: <4395D6E6.6090103@savvis.net> References: <9307f5f20512030807x6eadc73cq9d9acc9dd5503a5b@mail.gmail.com> <4391E320.2090006@savvis.net> <9307f5f20512031333x61e9d141u85ea578711740712@mail.gmail.com> <43936F6B.1090003@savvis.net> <1133819097.4559.15.camel@localhost.localdomain> <4394E242.7030401@savvis.net> <9307f5f20512051937h26e4a99awb00083dccca21180@mail.gmail.com> <4395D6E6.6090103@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
If I understand it well. 1. Write a d-bus interface for bluetooth. 2. Write a FreeBSD Bluetooth/d-bus. 3. Write a Linux Bluetooth/d-bus. 4. Write a KDE d-bus link. 5. write a GNOME d-bus link. 6. Nobody will complain. Another option. 1. Rewrite libkbluetooth with ifdef _BSD_ options. 2. Rewrite libgnomebluetooth with ifdef _BSD_ options. 3. Nobody will complain. So, everything is open. Somebody has (a lot of|some) work to do. But a lot of people will be very happy when it is all done. Ronald. PS: I didn't mention Solaris or other possible Unix/POSIX based bluetooth stacks. On Tue, 06 Dec 2005 19:22:30 +0100, Maksim Yevmenkin <maksim.yevmenkin@savvis.net> wrote: > Paul, > >>> 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. >> since coding gui applications in C is the second most boring thing on >> earth (the first being writing gui applications in asm :-) it's a >> good idea to do it in a higher level language, and since those >> clients have to communicate over dbus with the daemon, you'll need >> dbus bindings for your language of choice, and dbus does have them. > > perhaps i'm wrong, but you seem to be thinking about this in terms of > gui. if so, then i can compare it to building a house starting from the > roof. without foundation and walls it will fall down. > > gui, imo, should be the very last thing to worry about. it will be > trivial to write any gui when you have defined low level api. if you > like you can use d-bus or whatever messaging protocol of the day. > >>> 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? >> I think marcel was talking about a dbus replacement for hcid, the >> linux bluetooth daemon. (after all HCI is part of the bluetooth >> specification and you can't replace that one :-) > > again, what is _wrong_ with raw hci sockets? > >>> 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? >> yes, that's how it would work in an ideal world... in this world, >> bluez has one way of doing things, freebsd has another, for example >> freebsd had its SDP api rewritten from scratch even if sdp has very >> little low-level programming involved and could easily have borrowed >> the bluez sdp code, but we all know licensing issues are a Bad Thing >> so let's not get over this again please. In the end, if you have a >> well-defined d-bus interface, you'll have applications that DO run >> regardless of the os. >> >>> what about not-kde/gnome/whatever applications (i.e. non-d-bus)? >>> are those just out of luck? >> fell free to suggest alternatives, but all the major linux >> distributions now have dbus, freebsd does have it, solaris will come >> along (but I don't know if opensolaris has a bluetooth stack yet ;-) >> and after 1.0 is out it will become quite a standard (no, I don't >> like creating dependencies, and I like even less adding new >> "standards", I _have_ been looking for alternatives, if there was a >> common low-level api probably noone wouldn't need a d-bus layer in >> the middle but this is not the case so...) > > as i tried to explain, the alternative would be common low level api. > > please, PLEASE, accept the fact that other (than linux) systems do > things _differently_. please do not think that you could just port d-bus > and/or whatever to freebsd/solaris/etc. but rather understand that the > major requirement is that bluetooth should be usable on out-of-the-box > system. in particular, on freebsd that means, i do not have to install > _any_ third party application, etc. > > if/when d-bus will be included into the base freebsd installation, i > will not have any problem with it. until then _any_ work based on > _optional_ software will be _optional_. which means we will have to > maintain two sets of bluetooth tools/libraries/etc. one is d-bus based > and other is not. imo, this is not going to solve the problem. > >>> i admit kde/gnome folks did a lot of work by integrating bluetooth, >>> but their work can not be re-used :( >> yes, that's the point >> >>> 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. >> but you could make a server which runs on top of the dbus interface, >> which isn't that bad. strictly speaking the only requirement is dbus, >> regardless of your favourite desktop manager; of course _clients_ may >> be more or less integrated into a particular desktop enviroment, for >> example some developer might want to implement an obex _client_ as a >> KIOslave for kde, another as a nautilus-vfs extension, yet another as >> something else, but the fact that there are soo many desktop >> environments to chose from (like the fact that every operating system >> has his own low-level api for the bluetooth stack) and that there's >> no established standard among them is something we have to live with >> :-( > > like i said, d-bus is likely not going to help you here. at least, not > on freebsd. everybody should sit down and talk. perhaps even write a > draft and send it to bluetooth sig, so they can publish it as a standard. > > thanks, > max > > _______________________________________________ > freebsd-bluetooth@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth > To unsubscribe, send any mail to > "freebsd-bluetooth-unsubscribe@freebsd.org" -- Ronald Klop Amsterdam, The Netherlands
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.s1d7mdaa8527sy>