[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: File formats
- To: Tuomas Lukka <lukka@xxxxxxxxxxx>
- Subject: Re: File formats
- From: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Date: Fri, 01 Sep 2000 19:50:31 +0200
- Cc: zzdev@xxxxxxxxxx
- References: <Pine.HPP.3.96.1000827150900.16982C-100000@xxxxxxxxxxxxxxx>
A number of issues:
- The fragility you mention would be horrible. We need a system which
can be updated. We need a system in which we can EXCHANGE versions
between different systems where different keystrokes are implemented.
- However, we do want to be able to version on keystroke granularity,
i.e. if I hit undo, one whole keystroke has to be undone; I gain nothing
if my cursor then is lost because I moved it, which necessarily
disconnects it for a moment (in both the old and the new cursing system).
- We want an optional finer grained versioning, too, for debugging.
- We need a compression algorithm that makes our versions smaller.
- We need a recovery tool that is able to perform a rollback on
commandline (i.e. "rollback 19:30" for rollback to the state of today,
7:30pm, should be able to make my storage work again after a crash).
- We need a tool to delete old versions. ("Deleting" means that a number
of version changes is collapsed into a single version change, I suppose.)
- A possible compression algorithm would be to store the code of the ZZ
system in the space -- esp. after bootstrapping -- so that we really
*know* what this call did at this time.
- We would then write "deterministic calls" to the file as one single
record. "Deterministic calls" are calls which do the same every time
they are executed in the same zz space ("read the file tree into a zz
structure" would, for example, not be a deterministic call).
jm2c.
-b.
Tuomas Lukka wrote:
>
> The save format will need to evolve - I've been talking with Ted and would
> also like your comments on this.
>
> The basic fundamentals are that
>
> 1) the current format grows too fast and too large
>
> 2) the users should have a clear model of what is what and control over
> the storage
>
> Ted suggests saving explicit version and keystroke (actually event, since
> mouse is included) lists between them. However, these have their own
> problems:
>
> - fragility: changing the meaning of a keystroke even slightly can totally
> screw up the steps so that the interval between versions becomes
> inaccessible.
>
> - space: storing all the insignificant things as well (cursor moves, mouse
> drags) may in fact use more space than the current system.
>
> However, some change is necessary. I don't know what it should be yet.
>
> Tuomas