* Continued discussion of startup behavior As mentioned in the 12/15 notes, the file dependencies don't have as much functionality as we really need right now. The alternative Liane and I discussed was to have nwamd disable, then enable network/location after writing out the location config files; this will cause a re-evaluation of the service's file dependencies, and notice that the files are now there. Alternatively, Alan suggests that fixing CR 6227518 would make a service restart sufficient; and the restart will not enable a previously disabled service (we don't want to override the admin's explicit disable of the service, even if that seems like a bad idea).
* Legacy location Section 8.2 of the phase 1 spec[1] discusses when the legacy location (the location configuration values that are in place when nwam is enabled, which need to be restored when nwam is disabled) should be saved, written out to the filesystem, etc. However, the current algorithm results in the data being written and read on every restart of the nwam service, which results in nwamd doing a lot of extra work, and also potentially overwriting the values it really cares about. After some discussion, we decided we could make things better by modifying the section 8.2 algorithm slightly. The legacy location should be saved on startup if a legacy location does not already exist. On shutdown, the nwam service's general/enabled property will be checked; if it is false, we know nwam has been disabled, and will write out the legacy location, and then destroy that location (so that the potentially new values will be saved at the future time when the nwam service is re-enabled). [1]http://www.opensolaris.org/os/project/nwam/p1spec/netsvcs/
