Alan Maguire wrote: > 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! >
If this is really an issue, then we are going to need the concept of all actions in a UI being elements of a large transaction - where when the UI starts, you start a transaction, do all the changes you want, and then when the UI exits any commits done in that transaction can be acted upon or ignored - this would work for the CLI and GUI modes of operation. In some ways the GUI is doing this for the main part, it doesn't commit changes to an NCP until the very end, but there could be bugs here (e.g. a remove may happen too soon) - but that would be a bug in the GUI, and could be delayed until the user presses OK. But saying that some things are a little more immediate, e.g. editing of wireless favourites, editing of ENMs are committed at the click of OK on that dialog, etc. but they should be fairly coarse in general terms. I too can see how a small change at a time could be quite disruptive and confusing to boot. It may be useful to be able to measure how disruptive things are once we've everything up an running - and then work to change that - it's just not clear to me how to measure that right now. Thanks, Darren.
