Hi Bastien, > > all implementations should use the new D-Bus interface only. Using the > > Bluetooth library from BlueZ is not portable. For the configuration of > > the local adapters, searching for new devices and handling trusted > > devices everything is already in place. > > Sounds fair. But libbtctl currently uses bluez-libs directly. We'll be > migrating to the D-Bus bindings as it goes, but throwing away all the > work already done would be a waste of time (especially given that the D- > Bus interface isn't available in any released distros).
you can use libbtctl as a wrapper on top of either bluez-libs or the D-Bus API if you wanna support older installations. On the other hand the newly D-Bus API is that simple, that you might simply switch. > > For the file sharing a D-Bus enabled OBEX server (OPP, FTP and even BIP) > > is needed. Feel free to post thoughts about an interface for it to the > > BlueZ developer mailing list. > > Right now we're using the bluez-libs and openobex for gnome-obex-server > and gnome-obex-send, and unless there are major breakages, we don't > intend to switch to a d-bus based server. We have the concept of passkey agents now. This allows an application to get PIN code requests for a specific remote device. We also talked about the concept of authorization agents, but we put that on hold for now. It might be a topic for an OBEX server. However one big advantage of having an D-Bus enabled server is, that you can use every programming or scripting language to configure it. It is a great thing to have a small Python program to do some stuff. Regards Marcel _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
