http://defect.opensolaris.org/bz/show_bug.cgi?id=9803
--- Comment #2 from amaguire <alan.maguire at sun.com> 2009-07-01 01:20:34 --- (In reply to comment #1) > I'm not sure that I agree 100%. > > I think that it is useful to listen for events still - especially if using the > "interact -v" mode. since nwamd is still sending them - to not do so would > break the usefulness of this tool. > The difficulty here is that the events pile up while waiting for input, and as a consequence the event queue is destroyed by nwamd. We could use multithreading, but I'm wary of investing too much in such a basic tool. It's my belief now that the model for nwamadm interact is wrong - we should actually be using the synchronous nwam_wlan_scan(), nwam_wlan_select() and nwam_wlan_set_key() interfaces to carry out commands such as: nwamadm scan-wifi iwk0 nwamadm connect-wifi -e essid <-b bssid> iwk0 nwamadm set-wifi-key -e essid -c wep|wpa -k keyname value ...rather than waiting for nwamd to tell us it needs such information. "nwamadm interact" could be renamed to be "nwamadm show-events". The problem is the GUI has a lot of intelligence about the state of objects on startup (is there a link NCU waiting for a wifi key etc) that nwamadm doesn't have. Without that it's not possible to trigger the appropriate (e.g. need key) event that requests user input. I'd like to see us move in the direction of deprecating nwamadm interact and replacing it with something along the lines of the above subcommands. Not sure how feasible that is in the immediate time-frame of course. > Also, w.r.t. when waiting to enter a value, it should be acceptable to enter > nothing (as in just press return, or a "do nothing" item in the list) and have > nwamadm simply do nothing, just continue to show events, react to events, etc. > until the next need for a prompt. Seems reasonable. -- Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
