Daemon News Ezine BSD News BSD Mall BSD Support Forum BSD Advocacy BSD Updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automatic bluetooth device initialization

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.


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@xxxxxxxxxx> wrote:


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.


freebsd-bluetooth@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@xxxxxxxxxxx"

 Ronald Klop
 Amsterdam, The Netherlands