The title pretty much say what I need
1) Retrieve the page - page must not be changed starts NOW 2) Do something what requires user input, possibly may last few minutes 3) Save the page ONLY if it wasn't changed, if it was, go back to step 1
this all needs to be done using API, I thought that edit token would help me here, so that I would fetch the token at step 1 and edit using it at step 3, hoping it expire if someone edit the page meanwhile. But this doesn't seem to work according to documentation, because edit token is only changed when user logout.
Is there any super-safe and proper method to do this? Preferably something more reliable than just storing the timestamp and comparing it (in theory someone could edit the page even in short time when timestamp is compared). I need some super-safe lock that prevent all possible race conditions here.
Just to make it clear:
1) Retrieve the page, store last edit time as TIME 2) Do something what requires user input, possibly may last few minutes 3) Retrieve the page history << Possible race condition here, what if someone edit the page before step 3 and 5 4) Compare time of last edit in page history with TIME in order to check if page was edited << Possible race condition here, what if someone edit the page before step 4 and 5 5) Edit
This is not what I need ^ I need something better :-)
On Wed, Jan 22, 2014 at 12:41 PM, Petr Bena benapetr@gmail.com wrote:
The title pretty much say what I need
- Retrieve the page - page must not be changed starts NOW
- Do something what requires user input, possibly may last few minutes
- Save the page ONLY if it wasn't changed, if it was, go back to step 1
this all needs to be done using API, I thought that edit token would help me here, so that I would fetch the token at step 1 and edit using it at step 3, hoping it expire if someone edit the page meanwhile. But this doesn't seem to work according to documentation, because edit token is only changed when user logout.
Is there any super-safe and proper method to do this? Preferably something more reliable than just storing the timestamp and comparing it (in theory someone could edit the page even in short time when timestamp is compared). I need some super-safe lock that prevent all possible race conditions here.
On Jan 22, 2014 7:41 AM, "Petr Bena" benapetr@gmail.com wrote:
The title pretty much say what I need
- Retrieve the page - page must not be changed starts NOW
- Do something what requires user input, possibly may last few minutes
- Save the page ONLY if it wasn't changed, if it was, go back to step 1
this all needs to be done using API, I thought that edit token would help me here, so that I would fetch the token at step 1 and edit using it at step 3, hoping it expire if someone edit the page meanwhile. But this doesn't seem to work according to documentation, because edit token is only changed when user logout.
Is there any super-safe and proper method to do this? Preferably something more reliable than just storing the timestamp and comparing it (in theory someone could edit the page even in short time when timestamp is compared). I need some super-safe lock that prevent all possible race conditions here.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Starttimestamp and basetimestamp?
-bawolff
In documentation I see:
basetimestamp: Timestamp of the base revision (obtained through prop=revisions&rvprop=timestamp). Used to detect edit conflicts; leave unset to ignore conflicts starttimestamp: Timestamp when you obtained the edit token. Used to detect edit conflicts; leave unset to ignore conflicts
What is difference between these two? Documentation say that there is only 1 edit token which is changed only when user log out / log back. However that makes no sense when description of starttimestamp tell something about "Timestamp of token".
Is there really only 1 edit token? Is it really same for all pages? Does it really change only when user relog? How does it change for IP users?
On Wed, Jan 22, 2014 at 12:47 PM, Brian Wolff bawolff@gmail.com wrote:
On Jan 22, 2014 7:41 AM, "Petr Bena" benapetr@gmail.com wrote:
The title pretty much say what I need
- Retrieve the page - page must not be changed starts NOW
- Do something what requires user input, possibly may last few minutes
- Save the page ONLY if it wasn't changed, if it was, go back to step 1
this all needs to be done using API, I thought that edit token would help me here, so that I would fetch the token at step 1 and edit using it at step 3, hoping it expire if someone edit the page meanwhile. But this doesn't seem to work according to documentation, because edit token is only changed when user logout.
Is there any super-safe and proper method to do this? Preferably something more reliable than just storing the timestamp and comparing it (in theory someone could edit the page even in short time when timestamp is compared). I need some super-safe lock that prevent all possible race conditions here.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Starttimestamp and basetimestamp?
-bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The time you obtained the edit token has nothing to do with the uniqueness of the token, or the effective life time of the token.
I believe starttimestamp is just any edit after this point is a conflict, where base timestamp should match the timestamp of the base revision. Thus the difference between them is you give them different values.
-bawolff On Jan 22, 2014 7:52 AM, "Petr Bena" benapetr@gmail.com wrote:
In documentation I see:
basetimestamp: Timestamp of the base revision (obtained through prop=revisions&rvprop=timestamp). Used to detect edit conflicts; leave unset to ignore conflicts starttimestamp: Timestamp when you obtained the edit token. Used to detect edit conflicts; leave unset to ignore conflicts
What is difference between these two? Documentation say that there is only 1 edit token which is changed only when user log out / log back. However that makes no sense when description of starttimestamp tell something about "Timestamp of token".
Is there really only 1 edit token? Is it really same for all pages? Does it really change only when user relog? How does it change for IP users?
On Wed, Jan 22, 2014 at 12:47 PM, Brian Wolff bawolff@gmail.com wrote:
On Jan 22, 2014 7:41 AM, "Petr Bena" benapetr@gmail.com wrote:
The title pretty much say what I need
- Retrieve the page - page must not be changed starts NOW
- Do something what requires user input, possibly may last few minutes
- Save the page ONLY if it wasn't changed, if it was, go back to step
1
this all needs to be done using API, I thought that edit token would help me here, so that I would fetch the token at step 1 and edit using it at step 3, hoping it expire if someone edit the page meanwhile. But this doesn't seem to work according to documentation, because edit token is only changed when user logout.
Is there any super-safe and proper method to do this? Preferably something more reliable than just storing the timestamp and comparing it (in theory someone could edit the page even in short time when timestamp is compared). I need some super-safe lock that prevent all possible race conditions here.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Starttimestamp and basetimestamp?
-bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Jan 22, 2014 at 4:11 AM, Brian Wolff bawolff@gmail.com wrote:
I believe starttimestamp is just any edit after this point is a conflict, where base timestamp should match the timestamp of the base revision. Thus the difference between them is you give them different values.
basetimestamp corresponds to wpEdittime in the web UI. If this doesn't match the top revision's timestamp, it is an edit conflict (which might be automatically resolved, just as with the web UI). Omitting it prevents any detection of such edit conflicts, meaning you're likely to just overwrite someone else's edit.
starttimestamp corresponds to wpStarttime in the web UI. It is used to detect situations such as "article was deleted since I started editing it". Omitting it means that you might recreate an article that has been deleted, or restore the deleted version if the article was deleted and then partially restored.
this explanation should be in the documentation ;)
anyway I guess I need to use both of them?
On Wed, Jan 22, 2014 at 8:22 PM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Wed, Jan 22, 2014 at 4:11 AM, Brian Wolff bawolff@gmail.com wrote:
I believe starttimestamp is just any edit after this point is a conflict, where base timestamp should match the timestamp of the base revision. Thus the difference between them is you give them different values.
basetimestamp corresponds to wpEdittime in the web UI. If this doesn't match the top revision's timestamp, it is an edit conflict (which might be automatically resolved, just as with the web UI). Omitting it prevents any detection of such edit conflicts, meaning you're likely to just overwrite someone else's edit.
starttimestamp corresponds to wpStarttime in the web UI. It is used to detect situations such as "article was deleted since I started editing it". Omitting it means that you might recreate an article that has been deleted, or restore the deleted version if the article was deleted and then partially restored.
-- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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:
1. Get the ID and timestamp of the last revision. 2. Get the text of that revision. 3. Do long-running computation based on that text. 4. POST an edit (resulting from that computation) with basetimestamp set to the timestamp obtained in #1.
will cause a race condition.
Matthew Flaschen
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
On Wed, Jan 22, 2014 at 12:41:30PM +0100, Petr Bena wrote:
- Retrieve the page - page must not be changed starts NOW
- Do something what requires user input, possibly may last few minutes
- Save the page ONLY if it wasn't changed, if it was, go back to step 1
The way we should *cough* do this is If-Unmodified-Since.
http://restpatterns.org/HTTP_Headers/If-Unmodified-Since
It should be passed a value that matches a Last-Modified value that we get from the previous "fetch page contents" API call.
But, I'm not convinced we could do this with our current API setup... I think there are too many overlaps between things. Last-Modified may apply, in this case, to the text of the page you're fetching, or, since you can batch requests, it may apply to the image information you're fetching, or the post count of the Flow board you're fetching, which may cock up your estimate. And how the API is supposed to know what part of the API call is constrained by the If-Unmodified header is beyond me. Then again, you could apply it to all of them, and just pass the date of your last request as the value.
I'd be interested to see this happen, but I suspect it would take a lot of digging. :)
On Fri, Jan 31, 2014 at 8:38 PM, Mark Holmquist mtraceur@member.fsf.orgwrote:
http://restpatterns.org/HTTP_Headers/If-Unmodified-Since
It should be passed a value that matches a Last-Modified value that we get from the previous "fetch page contents" API call.
Unfortunately, MediaWiki refuses to obey the HTTP spec. Hence the reason why we don't have E-Tag support either.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
On Jan 31, 2014 9:59 PM, "Tyler Romeo" tylerromeo@gmail.com wrote:
On Fri, Jan 31, 2014 at 8:38 PM, Mark Holmquist <mtraceur@member.fsf.org wrote:
http://restpatterns.org/HTTP_Headers/If-Unmodified-Since
It should be passed a value that matches a Last-Modified value that we get from the previous "fetch page contents" API call.
Unfortunately, MediaWiki refuses to obey the HTTP spec. Hence the reason why we don't have E-Tag support either.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The api uses http to transport things around, but ultimately it works on a higher layer than http for the final results. Thus it doesnt make sense to use http headers to describe parts of the returned content, anymore than it would make to use icmp packets to say page not found, since the individual parts of the api response are not the same as the entire response body, but form a higher application specific protocol. (Imo)
-bawolff
wikitech-l@lists.wikimedia.org