On Thu, Jan 23, 2014 at 9:22 AM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 01/22/2014 12:35 PM, Petr Bena wrote:
this explanation should be in the documentation ;)
anyway I guess I need to use both of them?
basetimestamp (the timestamp of the revision your edit is based on) should be sufficient. I might be missing something, but I can't think of a scenario where:
- Get the ID and timestamp of the last revision.
- Get the text of that revision.
- Do long-running computation based on that text.
- POST an edit (resulting from that computation) with basetimestamp set
to the timestamp obtained in #1.
will cause a race condition.
IIRC there'll still be some race conditions in the sense of programs due to that smart merge:
1. User A and User B fetch text; 3. User A moves paragraph 1 after paragraph 10 in their copy; 4. User B moves paragraph 1 after paragraph 20 in their copy; 5. User A and User B upload their modified text. The order of uploading actions is not critical; 6. Result: both edits got accepted; paragraph 1 got duplicated after paragraph 10 and 20 and removed from its original position.
just like what we do on Web UI. The key is we want to detect any mid-air edits and abort actions in this case, instead of trying to have my edit merged to any mid-air revisions.
-Liangent
Matthew Flaschen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l