Re: File formats

[Tuomas Lukka <lukka@xxxxxxxxxx>]

Ok, now finally to catch up on email.

> - 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).

This is how it works now - try the current undo.

> - We want an optional finer grained versioning, too, for debugging.

Works: there's a ZZSpace.stamp() function for making timestamps.
Currently they are made on completed operations, EXCEPT if text insertion
mode is used - the whole change to the text is one stamp.

> - We need a compression algorithm that makes our versions smaller.

Actually, it now works pretty small.

> - 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).

Hmm... yes, time is good. I'll put in the basic capability and store the
time but I don't have the time to polish it.

> - 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.)

Doable later.

> - 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.

Hmmm.. an interesting idea. But you need an abstract representation, since
you want to be able to use it on different platforms. But the abstract is
one step behind the not-abstract. Could it really work?

> - 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).

Sorry, I don't follow you here.

	Tuomas