undo?

[Bernhard Herzog]

Russell Nelson <nelson at crynwr.com> writes:

> Bernhard Reiter writes:
>  > On Thu, Jan 20, 2005 at 08:03:24PM -0500, Jonathan Coles wrote:
>  > 
>  > > however, i'm not sure that the whole session file should be a sequence
>  > > of commands. if it was, the only way to get the final state of the
>  > > session would be to run through all the commands from the beginning when
>  > > the session is loaded.
>
> Once you have the list of commands that created a session file,

What "commands" are we talking about exactly?  The menu commands for
instance are subject to change between versions to an extent, and what
actually do is somewhat implementation defined.  Also, extensions can
define new commands, yet it would be sad if that would mean you could
only load a session if you have certain extensions installed even though
those extensions don't really modify what information is stored in the
.thuban file.

> then *that* is the canonical representation of the current state of the
> session. 
> A dump of the current state would simply be serving as a
> cached copy of the state, and would not be authoritative.

I think it should be the other way round.  The description of the
current state of the session is the only really required part of the
file.  Any description of earlier states, e.g. in the form of commands,
should be optional.  There are at least two reasons why this should be
preferred: efficiency and privacy.

Usually you want to load the current state and you're only rarely
interested in the earlier states.  If you have to reconstruct the
session by repeating all the commands starting from an empty session (or
some other specific state, doesn't really matter) it's going to be
potentially quite inefficient, and over times it gets worse.  There's a
reason why CVS stores the most recent version of a file as is and diffs
for earlier versions.

If you store the history of the session in the .thuban file and later
give that file to someone else, they can also see all the changes you
made.  That might give them information you did not want them to have at
all.  So it should at least be possible not to include the history in
the .thuban file.  Maybe it should not be in there by default, although
that would reduce the benefits of the feature.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/