<div dir="ltr">On Tue, Jul 23, 2013 at 9:57 PM, Paul Norman <span dir="ltr"><<a href="mailto:penorman@mac.com" target="_blank">penorman@mac.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Where it might run into problems is if there is a scenario where a user<br>
uploads<br>
changes and then immediately requests the latest version from the API. In<br>
this<br>
scenario my service would of transparently proxied the main API for the<br>
upload<br>
then answered from its own data to the latest version request. The reply for<br>
the<br>
upload and the reply to the latest version request would then be<br>
inconsistent.<br>
<br>
On the other hand, I can't see when a client would actually do this.<br>
<br>
Is anyone aware of any clients where this scenario can come up, or of other<br>
scenarios where different API calls having different delays could matter?</blockquote><div><br></div><div>This is exactly what iD does and is what put a halt to me working on tiled OSM data for the time being.</div><div>

<br></div><div>iD clears out its internal representation of OSM data when a user's Save is successful and then re-requests the area in the viewport immediately. The replication delay for a read-only API needs to be less than 2 or 3 seconds in this scenario.</div>

</div></div></div>