Re: ppp using NM

[Dan Williams <dcbw redhat com>]

On Fri, 2007-11-30 at 00:25 +0100, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > >   For the DUN case, we don't want
> > > > to show the BT _adapter_ in the applet menu, we want to show _phones_.
> > > > So when your phone is around (requires scanning periodically I think?)
> > > > it'll pop into the menu, and it would work just like I posted in my blog
> > > > about how 3G cards would work.  You've got some connections, and they
> > > > apply to your phone, and you pick one.  That's it.
> > > 
> > > You can't go around scanning forever. People always ask that of
> > > Bluetooth, and you can't do it, especially with older BT 1.0 devices
> > > that can't scan and do something at the same time.
> > 
> > Ok, but we need a way to dynamically determine what's around.  Having to
> > request a scan to find your phone does not fit in the interaction model
> > here, and we shouldn't have to do that.  If the BT adapter isn't doing
> > anything, NM should periodically request scans.  If the BT adapter is
> > doing something, I assume you can't _manually_ scan with hcitool either,
> > so the point is moot.
> 
> we can't keep scanning around. Bluetooth is not designed like this and I
> have mentioned this multiple times now. It will get you the worst
> experience ever. Besides the unneeded power consumption (inquiry is an
> expensive operation) you will have problems if you have an HID or audio
> connection open. There is already enough interference in the 2.4 GHz
> band, you don't wanna make it more.
> 
> > What happens when you just power on the phone and the devices are
> > already paired?  Do they find each other?  Or do you still need to scan
> > to find the phone?
> 
> You can easily list already paired devices and you will get signals if
> new devices have been paired or if a bonding has been removed. So
> listing paired devices would be absolutely enough.
> 
> In the case a device is not in range when selecting it you get a page
> timeout. Same as if the access point has been switched off since the
> last time you've seen the beacon.
> 
> Also a device could be non-discoverable, but still connectable. In this
> case the scanning will not show the device, but it could be used. So
> scanning all the time gives you nothing. It wastes resources, blocks the
> baseband and consumes power.

Ok, fair enough.

> > > That, and it just drains your battery, and takes a long time to do
> > > (longer than looking for an AP using Wi-Fi).
> > 
> > I can't imagine the power drain for scanning is really that much more
> > than wifi, which is pretty negligible given how often NM (doesn't) scan.
> > There are intelligent ways to go about scanning.  Is it really that much
> > worse?  I don't think taking longer to scan is really a problem for the
> > interaction though, that's just something we have to suck up I think.
> 
> It is already bad in case of Wifi. It is not negligible. If there is no
> UI to update and you have a connection, there is no need to scan at all.
> However NM keeps scanning.

Precisely because you need a fairly complete picture of the network.  If
you walk out of range of the AP, you then need a good idea of what new
AP you should be connecting to.  If you unplug the ethernet cable, you
need a good idea of what AP to connect to.  You need to do this for
devices for which you'll automatically switch to.  I do not anticipate
automatically switching to a bluetooth connection, I believe that will
need to be a manual operation by the user.

> And we don't talk about the interference between Bluetooth and Wifi when
> we keep scanning all the time. Use a spectrum analyzer to see what
> happens. Bluetooth is designed in a way that makes it quite robust, but
> it has its limits. Wifi on the hand is not robust at all.

This is just something people have to suck up.  Until all laptops get
GPS units or accelerometers and until NM can figure out when you've
moved the laptop (or at least what the velocity is and for how long, and
therefore have an idea if you're moving in/out of wifi range), NM is
going to keep scanning periodically.  Drivers also quite suck here,
since only now are we beginning to see driver integration between BT and
WiFi chips to make sure they don't stomp on each other.

This is a question of user experience, and there is no way NM is going
to have a "Scan now" button, because that experience just sucks.  If the
system has the capability for dynamically investigating the environment,
and the costs aren't that high (as in wifi), then we need to use that
method to make the user aware of the surroundings.

NM backs the scan interval off to 2 minutes when nothing has really been
going on, which is a good compromise between responsiveness of the UI
and power/interference considerations.

> > > What we could do though, is show the paired phones as top-level objects.
> > 
> > You mean, even if the phone isn't on or actually available at the
> > moment?  I'd rather not do that if at all possible; because if the
> > device isn't there, it shouldn't really be shown, because the user can't
> > do anything with it anyway.
> 
> See my comment above. Scanning doesn't help you to determine if a phone
> is in range or not. It simply doesn't work this way.

Ok.  So we'll just show paired phones (that support the DUN profile of
course) in the menu whenever the adapter is plugged in.

Thanks,
Dan