Re: PPTP Plugin Updated -- Ver. 0.6.9 Generally PPP capable?

[Dan Williams <dcbw redhat com>]

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