gumnut-v0-demo-runner v0.1.2

This is a project.

• main document ("actual doc")
  • secondary/meta document for transient stuff (current users? what else?)
• main doc ends up with cursor data but only in ops, which is fine (discarded)
• is there a role for "overlay" ops?
  • breaks invariant that our ops always get applied after everything we see
  • but can help us "keep track" of our own cursor using same logic
  • think of it as: "always one unsent op"
  • needs to happen at very high level
    • "perform op but nono promise you won't" - key - NOT ACTUALLY APPLIED!
    • part of ClientDoc
• eventual attribution?
  • not sure, probably in doc (but not serialized directly to client - optional?)

• "load"/"commit"

  • replaces only clean or nonexistent fields
  • commit marks all as clean
  • (avoids version numbers)
  • "restore" to clean op? - or use history ... / different layer
  • maybe nested DirtyHolderType<ValueType>
    • but we care about (eventually) moves/changes on TreeType, too
    • maybe part of TreeType - can't avoid it - what is doing "load"/"commit" anyway?

• "load"/"commit" dance

  • build a canonical + shadow/change layer
  • could it be like LayerType<TreeType> or is there too much specific in it?
  • probably needs to be aware of the tree.. - values need to be copied before change, not "replacing" them
  • i.e., op is "delete 3 characters from long string" - what's the long string? tree needs to cp it
  • ShadowTreeType maybe