Does a client send the same kind of delta messages as it receives?

[enikao]

Is there any difference between the messages a client sends and receives via delta protocol?

A Different kind of messages per direction

Maybe the client sends "I'd like to change the property x of node y to z" and it receives either "property x of node y changed to z" or "property x of node y to zzzz" (e.g. because of some conflict resolution)?

Pro:

• If we conceptually think of "Command/Intent" as different from "Event", we should separate them also technically.

Con:

• Both directions might look very similar in terms of the possible messages, as everything a client does needs to be communicated to all other clients, and this protocol is very low-level.

B Same kind of messages per direction

Client sends "property x of node y changed to z" and receives the same kind of message "property a of node b changed to c".

Pro:

• Simpler
• Clients may communicate directly with each other (not really part of our scenario)

[dslmeinte]

I think a change should be initiated as a Command in CQRS-parlance, and then be broadcast by a repository as an Event. Commands and Events are often quite similar in payload, though.

[joswarmer]

I like B as it is much more clear.

[joswarmer]

Both clients and servers send deltas stating 'this has changed in the model'. So they do exactly the same and therefore I don't see why they should use different deltas.

[dslmeinte]

That does imply complete symmetry, so e.g. a repository can't reject a delta.

[joswarmer]

You are right, a repository can reject a delta, and a client cannot.

[slisson]

The idea of rejecting changes from the client could be generalized into something that alignes more with the OT approach.

In OT, conflicts are resolved by "transforming" an "operation" into a different one, which means replacing it with an operation that is equivalent to its original intent but valid to be applied on a different state of the model. Some conflicts can be resolved by giving one of the operations precedence and transforming the other operation into an empty one (NoOp).

Rejecting a change in OT terms means replacing it with a NoOp. Such a protocol would allow the server to apply more advanced conflict resolution strategies, but also allow the rejection strategy.

For the client it shouldn't be a big difference. In both cases it needs to be able to roll back its own changes and apply different ones.

[enikao]

Preliminary assumption on 2024-06-21: Option B

Rationale: We don't see a really good case for A (yet). If we decided in favor of #273, that might be a case for A.

[enikao]

Does this still hold with #280 event giveUpDeltasJustReload? It feels like this event can only be sent by the repository.

[enikao]

Decision: Option A: Distinct commands and events

Details see #291