Darren Kenny wrote: > Anurag S. Maskey wrote: > >> Renee Danson wrote: >> >>> On Tue, Mar 03, 2009 at 03:03:21PM -0500, Anurag S. Maskey wrote: >>> >>> >>>> Should a user be allowed to destroy an active/enabled location or ENM >>>> using nwamcfg? I think this should be fine. We call the _fini_event() >>>> which disables the the location or ENM. For locations, when the active >>>> location is disabled, conditions check is triggered and a new location >>>> actived. >>>> >>>> >>> Hmm. This seems like one of those cases where we either annoy users >>> who know what they're doing (by forcing them to deactivate a location >>> before destroying it) or we allow users who don't to stumble into a >>> weird state (by allowing them to destroy the active location and thus >>> have possibly unintended results from the destroy operation). I tend >>> to err on the side of trying to prevent confusion, so I would lean >>> toward not allowing users to destroy the active location. >>> >>> >>> >>>> What about NCUs and NCPs? Only "User" NCP and its NCUs can be >>>> destroyed. Should this allowed if the User NCP is active? If so, then >>>> we divert to the Automatic NCP. >>>> >>>> >>> Same argument applies here. I think the behavior should be the same >>> for both locations and NCPs, and would prefer not allowing active >>> profiles to be destroyed. >>> >>> >> When you said that destroying the active location can have unintended >> results, that led me to think about it more. Even changing the active >> location (or any other entity), can have unintended results. This >> means we should not allow any modifications to active locations, enms >> and ncps and its ncus. Any active entity should be read-only, >> non-modifiable. >> > > Hmm - introducing a blanket change like this could have a really negative > effect > on the GUI's usability - especially if it's applied to properties within an > active object. > > Fine, I can understand that an object shouldn't be deleted if it's the active > object, and that's do-able. Similarly w.r.t. the editing the user modifiable > NCP > when it's currently active. > > I was of the understanding that thinks should be handled atomically - and as > such a change wouldn't be that severe, but if that's not the case things are > going to be very unusable in the GUI... > > For example, to edit the User NCP, the user would first have to switch to the > Automatic NCP, and then make changes and then switch back to the User NCP - > personally I can't see people liking that... > > I agree - what were the other nasty side-effects people had in mind that might occur if we allowed editing (as opposed to destruction) of active objects? I had thought that by giving nwamd a kick every time an object changes (which in turn is propogated to all listeners, telling them to refresh) we handled most cases. What am I missing here? Thanks!
Alan > Thanks, > > Darren. > _______________________________________________ > nwam-dev mailing list > nwam-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-dev >
