Anurag, Alan, Michael and I had a con call this morning, where we walked through some of the details of the phase 1 implementation. My notes are included below; additions/corrections/questions are welcome.
-renee * Problem with Automatic IP NCUs: their only activation rule is that they should be activated if their underlying link is active; but that dependency/condition is implicit for *all* IP NCUs, so it would be confusing for that to show up here but not in user-created NCUs. Discussed whether or not activation mode was even needed for IP NCUs; is it sufficient just to specify the underlying link's activation mode? Conclusion: we will remove the activation mode and related properties from IP NCUs (i.e. these properties will become specific to link NCUs). Alan will include this with some other libnwam work he has in progress (removal of under property from all NCUs). * What should happen when new links are added to the system? The active NCP should reflect their availability (the user should not have to actually create a physical link NCU); but should the new link be enabled by default? Yes in the case of the automatic NCP; but what about the user NCP? We can imagine scenarios where the user made simple policy changes (ordering wired interfaces, for example), but still expects this sort of "automatic" behavior. On the other hand, this might not be what's wanted by someone who has an elaborate, customized NCP. One possibility would be to have either a template (default set of property values for new NCUs), which may be modified by the user; or maybe just a per-NCP property that says whether or not new links should be enabled by default. Conclusion: for now, new link NCUs will always be enabled, under the assumption that this is the "expected" behavior by users who haven't fiddled much with NCP configuration; users who *have* done so and might expect something different at least would know how to take corrective action if needed. Implementing one of the configuration knobs we discussed will be a post-phase 1 RFE. * Per-NCP properties (one of the possible configuration knobs for the new-link question) would be more generally useful; an example is the need for a read-only property for the automatic NCP. * GUI vs. CLI capabilities: what happens if the GUI, which deliberately attempts to simplify things for users who aren't trying to do complex things, loads a configuration created by the CLI which contains elements that it cannot represent? Conclusion: with the current (phase 1) set of options, we don't think this is a risk; but it's definitely something to think about as we start adding support for more advanced configurations. * WLAN list manipulation: The current phase 1 API does not include the ability to modify the list of known WLANs. In phase 0, this was possible, though it required editing the text file. In phase 0.5, the GUI allows you to modify the list, using some basic libnwam functions. We discussed making this list another library object, which would be operated on with a set of functions much like the existing objects. This would be a non-trivial addition to the phase 1 work. Another possibility might be to keep the existing interface, and look at updating after phase 1 is completed. In any case, we can't have a regression here: the user needs to be able to modify the list via the GUI.
