Peter Tribble wrote: > 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". >
+1 and the idea of being able to say "save the current config" is novel & new. Darren
