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...

Thanks,

Darren.

Reply via email to