> > so if we mandate that every operation must modify the peristent
 > > repository and also track the corresponding undo_action
 > > in a journal, then the "undo" for a create is to just move
 > > the information from the persistent repository to the journal,
 > > right?
 > 
 > I don't think we're speaking the same language.  The "undo" for any
 > operation would have to take something from some hypothetical journal
 > (no-one has specified whether this journal is the repository data itself
 > or a series of commands that operates on the repository) and apply it to
 > the repository.  Not the other way around.

FWIW, I dislike the notion of building "undo" into the core admin model.
For one, it can fail.  For two, it introduces its own dependency
complexities (e.g., if another administrative subsystem creats an object
"a" which has a dependency on "b" and b" needs to be undone at boot,
now coordination and complexity is needed to handle wha happens to "a",
and get the ordering right).

The current dladm model isn't perfect but so far I prefer it to the other
approaches that have been floated.

-- 
meem

Reply via email to