On Tue, Jan 27, 2009 at 8:33 PM, Sebastien Roy <Sebastien.Roy at sun.com> wrote: > > On Tue, 2009-01-27 at 15:24 -0500, Sowmini.Varadhan at Sun.COM wrote: >> On (01/27/09 15:20), Sebastien Roy wrote: >> > >> > Consider the following three classes of administrative events on an >> > object: creation, deletion, and modification. In the case of creation, >> > it's easy enough to "undo", it's a simple deletion. The other two are >> > harder. The log has to keep track of how to re-create an object that >> > was deleted, or how to unmodify an object that was previously modified. >> >> I'm not sure I understand: if you were doing "delete -t", then you would >> simply not remember the action in your persistent store, right? >> Similarly for modify? > > That is essentially what is being objected to; the implementation of > temporary operations that have no effect on the persistent repository. > > The idea being proposed is that every operation results in modification > of the persistent repository, but that the persistent repository that > was modified is reverted to a previous known state.
I'm not a networking person. I'm a systems administrator. I would humbly suggest that involving systems administrators in these discussions would be a good thing. So just for my own personal opinion, I do not want the model where everything I do is tagged as persistent. Non-persistent should be the default. If I'm typing commands, normally it's because I'm in experimental or debugging mode. If I want to make persistent changes then I'll automate or script or just go behind the back of the commands and edit the config file. What *would* be really useful is a way of saying "hey, this is just perfect, now save the current configuration". Just my 2c. Others will undoubtedly view the problem differently. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
