Repository does not need to keep a history (of commands)

[enikao]

Is a compatible repository required to keep a history of all commands clients sent?
This can be helpful (probably even necessary) for live collaboration.

The difference to #294 is in what we mean with "history": Here, we talk about all changes that happened to the model.
In principle, we could recreate the current state of the model by executing all these changes in order, from the very beginning. There is only one linear set of applied commands, even though they might cancel each other out, e.g. if we first created a node, and deleted it again later.

Option A: Repo must keep a history of commands

Pro:

• Reliable source for live collaboration

Con:

• Might need a lot of storage
• Would only make sense if we had an API to access previous states in that history

Option B: Repo can chose to keep a history of commands, but doesn't need to

Pro:

• Probably needed for live collaboration support (Repo API: Versioning / Collaboration #26)
• One possible way of storing the repository content (aka event sourcing)

Con:

• More possible variants a client might need to deal with
• Might need support for Do we support capabilities? #218

Option C: Repo should not keep a history of commands

Pro:

• Clients can make some assumption that deleted data is actually gone (might be relevant e.g. for GDPR)

Con:

• Probably prohibits live collaboration
• No way to enforce it anyways

Decision: Option B

Option A might be too resource hungry, option C cannot be enforced. B is a good compromise.
We accept the increased variability.

[enikao]

Do we distinguish between commands that can never be correct or only the current state?
Example: change a property of a node
a) that node never existed
b) that node has been deleted

==> No, cannot without keeping a history