Do we include the optional parameters in delta events?

[enikao]

For most events, there's some information that might be useful for the receiving client, but not strictly necessary.

Example: moveChild

We need these parameters:

• newParent: TargetNode
• newContainment: MetaPointer
• newIndex: Index
• movedChild: TargetNode

The following parameters might be useful, but can be calculated from the required parameters, given the receiver knows the model:

• oldParent: TargetNode
• oldContainment: MetaPointer
• oldIndex: Index

Related: in removal cases (e.g. removeChild), do we want to send only the removed id or the whole node?

Pro:

• Receiving clients can make a better decision whether they need to react on that event.
  Examples:

  • For moveChild, if my editor does show the oldParent, the editor knows it needs to update. However, it also knows it shows movedChild, so not much won.
  • For removeChild, a processor might only care about instances of a specific concept. If the whole node is included, the processor can check its metaPointer without loading the model.

• Both participants can make better judgement whether the other side's view of the world is consistent with own view.
  Is this useful? What to do with a detected inconsistency?

• Repo should have minimal assumptions about the client and its state, but provide means for the client to update / detect issues / merge

Con:

• More transmitted data
• Might be cumbersome for the sending client to gather that information

[enikao]

Idea: Make it configurable per client connection. Client can chose whether it wants/provides optional info or not

Pro:

• Flexible
• Caters to both clients with full model knowledge and only reacting on deltas

Con:

• Repo has to create different kinds of delta per client

[enikao]

Decision: Always include optional parameters

Having them configurable introduces too much variability.
We can re-evaluate this decision if we see the protocol to be too chatty, or the optional parameters rarely being used.