Does a delta client apply its own changes locally or only after confirmation of repo?

[enikao]

Assume an editor client changes property x of node y to z, because the user initiated that change. When does the client apply this change to its internal model representation?

A Directly on edit

The client considers z to be the real value of y.x immediately.

Pro:

• No "dirty edit state" on client
• Good user feedback
• Supports offline clients

Con:

• Might lead to weird results with concurrent edits

B Directly on edit, repo might correct

The client considers z to be the real value of y.x immediately, but should consider the repo sends corrections.

Pro:

• Good user feedback
• Supports offline clients

Con:

• More complex client implementation

C Tentatively on edit, with confirmation/correction from repo

Client considers z to be the "dirty updated" value of y.x. Only after the repo replied the client knows the real new value.

Pro:

• Good user feedback
• Partial offline clients

Con:

• Needs dirty state tracking in client

D Only after repo confirmation/correction

Client only changes its internal representation after the repo replied.

Pro:

• Easier to maintain consistent state between client and repo
• Client can handle local and remote changes the same way

Con:

• Potentially lagging user feedback

E Out of scope

Each client can decide on its own. LionWeb has no expectations.

Pro:

• Easier to spec
• Full flexibility for client

Con:

• Might be harder to formulate consistent delta protocol because of missing assumptions

[joswarmer]

This is not something we should say anything about in LionWeb, clients can internally do what they want. It is however interesting to look at the scenario's and see which ones can be (or do we want to be) supported by the (delta) protocol.

[dslmeinte]

I feel the difference between B and C is anyway quite small, although C is probably closer to the CQRS way of thinking. (See also https://github.com/LionWeb-io/specification/issues/271#issuecomment-2120051220) In that vein: a client is probably making its own life easier if all changes are a result of an event, in which case correcting the state is a matter is replaying a sequence of events from a base state/snapshot.

[joswarmer]

Instead of a "correct" from the repo, the repo can also "reject" a change, as in optimistic locking.

[enikao]

Instead of a "correct" from the repo, the repo can also "reject" a change, as in optimistic locking.

I'd prefer to keep locking out of this discussion.

[joswarmer]

I'd prefer to keep locking out of this discussion.

Indeed! I should have said that the repo can reject a change, just like it can reject a bulk api change.

[enikao]

Indeed! I should have said that the repo can reject a change, just like it can reject a bulk api change.

It only does that to avoid inconsistent trees, correct?

[joswarmer]

Yes, that is the only valid reason I see.

[enikao]

(Preliminary) decision on 2024-06-21: E

[enikao]

Decision: E

Rationale: tbd