On Wed, 2006-06-07 at 09:37 +0200, Marcel Holtmann wrote: > Hi David, > > > > >> This is a totally general PPPD plugin... > > > > > > > > So I imagine that now we can believe that in some time in the future > > > > NM will make those dialers (gkdial, gnome-ppp etc) obsolete? Yay! :) > > > > > > For this see http://fedoraproject.org/wiki/SummerOfCode/2006/TimNiemueller > > > > > > I'm working on it :-) > > > > This sounds like very interesting work, thanks a lot for looking into > > this! > > > > As you may or may not know Matthew Garrett (mjg59) is working on > > teaching HAL about Bluetooth devices including providing methods for > > discovering, pairing and querying a Bluetooth device for what services > > it provide. > > we will have a full D-Bus API for most common tasks in the next BlueZ > release. It will be bluez-utils-3.0 and we are just working on the last > few blocker bugs. My actual plan is to get it out this week. > > The API includes support for device discovery, pairing functions and a > couple of signals for stuff that might happen behind your back. So in > most cases there is no longer need to query stuff. However it doesn't > support service discovery at the moment. We need to rewrite the SDP > layer to make it fully asynchronous and there was simply no time for it, > but this will be addressed in future versions.
Here's the ideal NM situation. Users will need to pre-pair and preconfigure their BT devices for use with NM. We'll likely include an application that will allow users to scan for and select a BT device, pair with it, and set up the carrier-specific GSM/CDMA settings for the dialup connection. Once the BT device is set up and known to NetworkManager, NM will periodically request scans from BlueZ much like it does for wireless networks from wpa_supplicant now. If a "known" BT device is around and supports DUN, NM will show that device in its menu. The user will then be able to select that device and use it for a DUN connection. For this, we'll need a few things from BlueZ and HAL: a) dbus methods to request scans and return scan results, along with capabilities of each device (ie, DUN, handsfree, etc, or however that works) b) dbus methods to pair with a device. We _don't_ want NM to do the actual pairing or anything, but NM should be able to just call pair(), have whatever BlueZ dialog is need for PIN pop up, and then receive a return code of success or failure. c) dbus methods to retrieve the rfcomm serial port device name for a specific, paired BT device It doesn't really matter to me where I get the list of available BT devices from, whether it's BlueZ or HAL, but I'd rather get them from HAL if I can. Marcel, Matthew: does this match with your ideas for how apps would use BlueZ and BT infrastructure? Dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
