On Tue, Feb 10, 2009 at 02:40:01PM +0200, Tambet Ingo wrote: > On Tue, Feb 10, 2009 at 14:20, Daniel Wagner <[email protected]> wrote: > > On Tue, Feb 10, 2009 at 01:12:02PM +0200, Tambet Ingo wrote: > >> What would call the API you added (other than your test program)? > > > > Good question. I assumed this could be an option in the nm-applet. > > The problem is there's no place to put it there. There's no per-device > configuration location anywhere, all the configuration is NMConnection > specific.
Okay, I didn't realize this. > >> Who would want/need to use that UI? > > > > I can just write about the problem I wanted to fix. The time needed > > to recognize there is a new AP or an AP disappeared was just too long. > > Of course if you don't have a "fast" changing network setup this is not > > really problem. This is all about moving around with your laptop/device and > > if it takes 120 seconds to see there is a new AP and 360 seconds to > > remove the AP from the list is just a bit too long IHMO. > > Can you use wireless when you move that fast? :) Surely you can't stay > connected to any of the APs? My use case is not about to stay connected when I move around. This might be the next thing I'd like to look at. It is as you say "I want my wireless APs appear/disappear faster". Hopping from one hot spot to the next one (read: open AP) :) > > If I didn't get it completely wrong, connman uses continuously > > scanning to overcome this problem. > > That's exactly what I meant by being device specific. Connman only > cares about a few selected wireless cards that support passive > scanning, NM needs to also work on cards where a scan request takes > noticeable amount of time (when no other IP traffic could be sent). I was not aware of this problem, though I should have. Argh! > >> Is it wireless device specific? > > > > The patch allows to set the scan interval for each device separately. > > Basically the patch just changes default behavior in NM. The > > scan is still triggered through the wpa_supplicant interface. > > > >> If it's card specific, then we can do the right thing in the NM > >> without asking users to try random options if something doesn't feel > >> right. > > > > No, it is not card specific. Okay I think you are right about > > Sounds like it still is. Hmm, I think I don't understand you here. What do you mean with card specific? The thing you explaned above (passive/active scan)? I was talking about dependencies on hardware specific HW interface (madwifi vs. wext vs. cfg80211, etc.) > > offering users too many knobs to play with. How do you propose > > to "fix" my use case? > > I don't know much about wireless drivers, but maybe a new capability > for drivers, IW_SCAN_CAPA_SOMETHING? As I said I'm not sure where the scanning policy belongs to. > Dan or Helmut will have a better > answer. But having UI for something like "I want my wireless APs > appear/disappear faster" is certainly not a solution, everybody wants > that. Clearly, this is what we should aim for :) daniel _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
