6 ms·

Yes, In my opinion, you're missing the user experience aspect. Two of the three should be rejected - not overridden. - so the users get the feedback they expec

Yes, In my opinion, you're missing the user experience aspect. Two of the three should be rejected - not overridden. - so the users get the feedback they expect, rather than reloading the page and seeing something totally different. And yes - It's a trivial example, one defined by UX - but there are many examples of needing to reject a transaction that can't simply be overridden (or replayed later like simple addition/subtraction) - and I don't see how the authors proposal replaces two phase commit in something like that.

amelius 8y ago
But assume the system updates changes infinitely fast. Then assume user A makes a change, and only after 30 microseconds user B makes a change. Will user A now be confused because their change is overwritten by user B? If so, then the problem has nothing to do with the aforementioned situation and the UX should probably show: "user B is also editing this field" or something like that. The point is: it does not matter if the system is slow and rejects changes; because the effect to the user will be the same as in the "infinitely fast" case.
- zzzcpan 8y ago
  I think it's fair to assume no collaborative text editing would actually occur on that field at all. And so last write wins is perfectly acceptable strategy here and no coordination is actually necessary, and neither is necessary to inform the user about conflicting edits. For UX it might be useful to observe own edit, but that can be done completely locally with data only eventually propagating farther. Incidentally this is also pretty much the only way to make the edit reliably synchronized with the remote system, because users don't have perfectly reliable computers, perfectly reliable internet connections and won't wait long for anything.
- LukeShu 8y ago
  How fast the system makes updates has nothing to do with it. Premise: The current state is "foo". Alice would like to change the state to "bar". Bob would like to change the state to "baz". Alice and Bob are friendly (non-antagonistic) coworkers. Naive sequence: 1. Alice: READ STATE => foo 2. Bob: READ STATE => foo 3. Alice: SET STATE=bar 4. Bob: SET STATE=baz <-- this is where the "confusing"/"wrong" thing happened. Bob did not expect to overwrite his coworker's work. The solution is that instead of a naive "set", to use "test-and-set" operation.
  - polynomial 8y ago
    Bob may or may not be concerned with what the state is/was, and more concerned with what state the system needs to converge on. I take your point, although the assumption is that Bob wants to set state=baz IFF (if and only if) state==foo. However he may simply need the state to be baz, regardless what the previous state was.
    - munk-a 8y ago
      Many systems (especially caching systems) make a point of differentiating the `set` operation from a `check and set` operation (usually known as `cas`) in systems where both of these operations are available you are quite able to intelligently differentiate those two resolution states.
falcor84 8y ago
From the UX aspect, I actually would not expect it to be rejected. I would indeed expect to see something totally different than what I typed with a label nearby saying "Edited by $NAME 5 seconds ago"
- kiallmacinnes 8y ago
  I'd much rather see my edit form shown again, with my content still in it, and a conflict warning... Nothing worse than loosing that 20 minutes of typing to a conflict!
  - lixtra 8y ago
    But this is easy to do. Just embed a version number (or hash) in the form. If after submitting the version to be changed is not the same as in the form, then you know there is a conflict.
  - falcor84 8y ago
    Wow, 20 minutes is a long time to spend on a "Github organisations description". But yes, I'm absolutely with you on that. Whenever I need to submit a long text field in an online form, I got into a habit of always first copying the contents into my clipboard, to prevent myself from causing irreperable harm to things around me if the request fails. But going back to the UX, I would prefer that the site accepts my change and stores it in a journal (a-la git or Wikipedia), before overseeing it with the next change, so that I could easily revert to it or merge it with the newer change.
  - MaulingMonkey 8y ago
    I'd rather see the edit warning when multiple people are editing the same info before 20 minutes of typing even starts, and a interface for accessing history for the edge cases.

amelius 8y ago

But assume the system updates changes infinitely fast. Then assume user A makes a change, and only after 30 microseconds user B makes a change. Will user A now be confused because their change is overwritten by user B? If so, then the problem has nothing to do with the aforementioned situation and the UX should probably show: "user B is also editing this field" or something like that. The point is: it does not matter if the system is slow and rejects changes; because the effect to the user will be the same as in the "infinitely fast" case.

zzzcpan 8y ago
I think it's fair to assume no collaborative text editing would actually occur on that field at all. And so last write wins is perfectly acceptable strategy here and no coordination is actually necessary, and neither is necessary to inform the user about conflicting edits. For UX it might be useful to observe own edit, but that can be done completely locally with data only eventually propagating farther. Incidentally this is also pretty much the only way to make the edit reliably synchronized with the remote system, because users don't have perfectly reliable computers, perfectly reliable internet connections and won't wait long for anything.
LukeShu 8y ago
How fast the system makes updates has nothing to do with it. Premise: The current state is "foo". Alice would like to change the state to "bar". Bob would like to change the state to "baz". Alice and Bob are friendly (non-antagonistic) coworkers. Naive sequence: 1. Alice: READ STATE => foo 2. Bob: READ STATE => foo 3. Alice: SET STATE=bar 4. Bob: SET STATE=baz <-- this is where the "confusing"/"wrong" thing happened. Bob did not expect to overwrite his coworker's work. The solution is that instead of a naive "set", to use "test-and-set" operation.
- polynomial 8y ago
  Bob may or may not be concerned with what the state is/was, and more concerned with what state the system needs to converge on. I take your point, although the assumption is that Bob wants to set state=baz IFF (if and only if) state==foo. However he may simply need the state to be baz, regardless what the previous state was.
  - munk-a 8y ago
    Many systems (especially caching systems) make a point of differentiating the `set` operation from a `check and set` operation (usually known as `cas`) in systems where both of these operations are available you are quite able to intelligently differentiate those two resolution states.

falcor84 8y ago

From the UX aspect, I actually would not expect it to be rejected. I would indeed expect to see something totally different than what I typed with a label nearby saying "Edited by $NAME 5 seconds ago"

kiallmacinnes 8y ago
I'd much rather see my edit form shown again, with my content still in it, and a conflict warning... Nothing worse than loosing that 20 minutes of typing to a conflict!
- lixtra 8y ago
  But this is easy to do. Just embed a version number (or hash) in the form. If after submitting the version to be changed is not the same as in the form, then you know there is a conflict.
- falcor84 8y ago
  Wow, 20 minutes is a long time to spend on a "Github organisations description". But yes, I'm absolutely with you on that. Whenever I need to submit a long text field in an online form, I got into a habit of always first copying the contents into my clipboard, to prevent myself from causing irreperable harm to things around me if the request fails. But going back to the UX, I would prefer that the site accepts my change and stores it in a journal (a-la git or Wikipedia), before overseeing it with the next change, so that I could easily revert to it or merge it with the newer change.
- MaulingMonkey 8y ago
  I'd rather see the edit warning when multiple people are editing the same info before 20 minutes of typing even starts, and a interface for accessing history for the edge cases.