-
Notifications
You must be signed in to change notification settings - Fork 73
Improve history serialization and persistence #135
Comments
Today I have worked on changing the Our API allows to undo individual changes and, while we call Other than that, we cannot use the patch that we pop from the undo stack to compose it later when emitting a stopped changing event, because we would need to compose the inverse of it. This requires us to actually create a different patch, and not reusing the same one makes having Nonetheless, now that I have more background on how @nathansobo @maxbrunsfeld: how would you feel about not changing how we store |
I am ok with that for now. Refactoring to use the |
@as-cii I wanted to some up some of my thoughts on history serialization in case you're interested. Here's a potential set of steps that I think could put is in a better spot both design-wise and in terms of performance.
Compact Binary Patch Format
Patch.prototype.compact
that converts the internal representation of the patch from a tree to a flat buffer. This format would only supportgetChanges
by directly iterating the serialized data, which is easy with that library. Call this method at the end of each transaction to keep the history in a memory-efficient way.Patch.prototype.serialize
in terms of the same buffer format.It might make more sense to just serialize patches to buffers before storing them in the history and deserializing them on an as-needed basis. The
compact
approach where you actually storePatch
instances with a different backing store just seemed cool in that it maintains a nice programmatic interface, but it may be more trouble than it's worth in other ways.Incremental Persistence
I'm still concerned about repeatedly serializing the same history over and over again. It might not be a big deal once it's smaller, but if it is, I have this idea for incrementally persisting the state.
atom::buffers::/path/to/buffer.txt
(there may be precedent for the key delimiter so we should research).atom::buffers::/path/to/buffer.txt::modifiedContents
atom::buffers::/path/to/buffer.txt::undo::1
,atom::buffers::/path/to/buffer.txt::undo::2
,atom::buffers::/path/to/buffer.txt::undo::3
, etc. If you pop an undo entry, delete its record. If you build a new undo entry, increment the integer in the key. (You might actually want to decouple the undo and redo entry keys from the buffer's path and just synthesize an id that you reference from the path once to simplify rename.)It may be that the history never gets big enough to require this, but it would be a cool scheme for basically associate an infinite history with any file on disk in a persistent way. I think it might be pretty cool.
The text was updated successfully, but these errors were encountered: