Global atomicity requirements

[csarven]

It may be worthwhile to be explicit about global atomicity requirements in the spec and refer back to it where applicable:

• creation of containers in path component
• deletion of resources
• other lifecycles..

Potential errors should be reported from general (eg. can create nested containers?) to specific (eg. can modify target resource?)

[michielbdejong]

In #115 (comment) you already said that you didn't want to force Solid servers to be strongly consistent.

How does "globally atomic" differ from "strongly consistent"?

[csarven]

If I understand your correctly - as well as myself ;) - I think they are orthogonal. For example, returning a 202 would still be considered as atomic in that it has committed to processing the request. The result of that request (as a whole) may not actually succeed. Server could return 202 and then later may not be able to create a required sub-container before going ahead with PATCH-append.

[michielbdejong]

True, but remember that that is not what we decided. The proposal in #115 was to introduce the 202-based mechanism you just described, so that a 200 really means 'successful and final', and 202 means 'hm, i'll think about it'. But then in that conversation, you, Kjetil, Dmitri, Aaron, Justin, and Pat, all said that eventual consistency (i.e., the server responds with 200 before propagation is complete) should be allowed. I was against it (and maybe Tim should also chime in here), but rough consensus was reached on 27 November and the decision was taken that from now on, Solid app developers can not assume that a server will be strongly consistent.

I proposed that we should require servers to act on the latest version of resource state, but that was labeled as 'best practice', not 'required'.

What I described as "erasing things from the history books" was labeled as "eventual constency" in #91 (comment) by Dmitri, and that comment got thumbs up from both Aaron and Justin...

Long story short, I was against it, but I accepted the rough consensus that the group reached.

So with this issue, bringing up 'global atomicity', are you proposing we reopen that discussion?

[kjetilk]

I must admit, the word "global" confuses me in this conversation, but other than that, I note that consistency and atomicity are two different criterions. Perhaps both of you could clearify what you understand by those terms in this context?

[michielbdejong]

Removing the word global, atomicity for me would mean that if a single request has multiple effects, either all or none of them happen, and then indeed it does not imply consistency.

[csarven]

That's right. And, as I've said above: "I think they are orthogonal."

By "global", I meant along the lines of capturing common patterns or expected atomicity that would apply in different scenarios. I'm okay to rephrase suggestions.

[michielbdejong]

Ah ok, so given we consider them orthogonal, I guess your use of 202 in #137 (comment) confused me. So IIUC you just used 202 there as an example, right? And the following text (with 200 instead of 202) would also be correct, right?

For example, returning a [200] would still be considered as atomic in that it has committed to processing the request. The result of that request (as a whole) may not actually succeed.