You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: immanuel.scholz[at]gmx.de [Submitted to the original trac issue database at 2.09pm, Tuesday, 28th March 2006]
I suggest the following changes to the API:
Server tells on every data object the date of last modify. Alternative, he
can just send a timestamp on the overall response which must not be before
the edit time of the latest change (current server time fits ;).
The client must specify on each upload the timestamp he thinks is the latest
version (obtained by downloading).
The server reject an upload, if the timestamp sent is before the latest
change timestamp of the object to upload.
The text was updated successfully, but these errors were encountered:
Author: osm[at]gravitystorm.co.uk [Added to the original trac issue at 5.09pm, Tuesday, 21st April 2009]
This functionality has now been fixed with API 0.6. However instead of the timestamp of the latest version of the node/way/relation, it has been implemented with explicit version numbers instead. The server will now reject uploads where the client has the wrong version number.
Reporter: immanuel.scholz[at]gmx.de
[Submitted to the original trac issue database at 2.09pm, Tuesday, 28th March 2006]
I suggest the following changes to the API:
Server tells on every data object the date of last modify. Alternative, he
can just send a timestamp on the overall response which must not be before
the edit time of the latest change (current server time fits ;).
The client must specify on each upload the timestamp he thinks is the latest
version (obtained by downloading).
The server reject an upload, if the timestamp sent is before the latest
change timestamp of the object to upload.
The text was updated successfully, but these errors were encountered: