To summarize the results from our discussion earlier today: The Automatic NCP will to totally automatic with the following features:
* wired interfaces are preferred over wireless interfaces * all wired interfaces are in the same shared priority-group * all wireless interfaces are in the same exclusive priority-group * NCUs for hotplugged and newly discovered interfaces are created as above * NCUs are removed when interfaces are hot(un)plugged or not found during nwamd startup ** The result is that only interfaces that currently exist in the system have NCUs. The User NCP will be all manual. * The user does everything. * No NCUs will be added or removed by nwamd. * NCUs added with manual activation-mode will be enabled by default ====> Change this behavior to "disabled by default"? Upgrading from Phase 0/0.5 to Phase 1 * Known WLANs (for unique ESSIDs) will be created in the same priority order as in /etc/nwam/known_wifi_nets. * The existing /etc/nwam/llp file will be upgraded to the User NCP. * The User will be placed in the Automatic NCP. * manpage, spec, online help, wiki, etc. and release notes will say that the old configuration has been upgraded to the User NCP and users can switch to that NCP at the convenience. * The GUI may or may not do a one-time pop-up. Did I miss out any details? Anurag John Leser wrote: > Hi folks, > > I'm sending this out to close the loop on some hallways discussion > earlier today regarding how existing NWAM 0/.5 state will be handle > when the system is upgraded to phase 1. > > Prior to our discussion, the plan was that during an upgrade to NWAM > 1.0, existing NWAM state would migrated into the User NCP, and the > User NCP would be enabled after the upgrade. This differs from a > newly installed system, which starts out with the Automatic NCP enabled. > > Thus, we end up with a set of users who's systems are running with the > User NCP, just because they happened to get to NWAM 1.0 via upgrade > rather than fresh install. AFAIK, this is independent of whether > they ever customized their previous NWAM configuration through the GUI > or by editing the llp files. This is a problem for a number of > reasons, most importantly: > > * Users end up with non-default NWAM 1.0 behavior, having likely > never expressed a desire for non-default behavior. > > * It is a significant, unnecessary difference in system > state/behavior between freshly installed and upgraded systems. > > * If users might have either Automatic or User NCUs active for such > an unrelated reason as install method, the line between the User and > Automatic NCP becomes blurred to the point where the distinction is > not helpful. > > With phase 1.0, I think we really, really want the Automatic NCP to > work for most run-of the mill laptop/desktop use cases. Due to a > variety of factors, it is not possible to reliably determine if a user > ever modified the NWAM 0/.5 configuration, so we cannot base NCP > selection or upgrade strategy on whether the old environment was > customized. > > Having outlined the concerns with the current method, the solution we > are now considering for upgrades is: > > 1. At upgrade time, migrate existing NWAM state into the User NCP. > 2. Always activate the Automatic NCP after an upgrade. > 3. At first interaction with the NWAM GUI, inform the user that the > previous configuration has been saved in into the User profile, > provide information about how to activate that NCP, but encourage > trying/sticking with the Automatic profile. > 4. Augment #3 with release notes/other documentation. > > The exact manner and wording of step 3. will be critical. Darren, I > don't know if you have any suggestions for how best this can be > handled through the GUI. > > -John > _______________________________________________ > nwam-dev mailing list > nwam-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-dev
