Re: Automatic bluetooth device initialization

["P. Durante" <shackan@xxxxxxxxx>]

> 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.

> 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 :-)

> 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...)

> 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 :-(

regards,
Paul