[OSM-dev] [OSM-talk] Is there some lag in the backend data?
penorman at mac.com
Wed Jul 24 09:13:09 UTC 2013
> From: Andy Allan [mailto:gravitystorm at gmail.com]
> Sent: Wednesday, July 24, 2013 1:05 AM
> Subject: Re: [OSM-dev] [OSM-talk] Is there some lag in the backend data?
> On 24 July 2013 04:22, Ian Dees <ian.dees at gmail.com> wrote:
> > 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.
> The physics of this starts to make it impossible.
> Perhaps it's better to explore a sort of inverse "if-modified-since"
> header. Clients would be able to request an initial bounding box without
> any particular constraint, and assume that it's within a few minutes of
> being up-to-date. But after making an upload they could request a
> bounding box with "only if replicated since: <timestamp>".
> The server can then indicate that it can't fulfill the request and the
> client retries later, or the server could proxy the request to the main
> API, or something else.
I think the solution is for the client (iD) to parse the server's
response to its changeset upload. The server gives all the information
necessary to avoid the client having to do a data update. If for some
reason the client feels the need to automatically discard it's dataset
it could download new data then apply the diff it has from the changeset.
> P.S. This is why I'm focussed on db-level replication for scaling API
> read requests, but we should work this through and be able to choose
> between alternatives!
DB-level replication is generally faster but it can lag behind too. As
we scale out horizontally clients will have to be prepared for a delay
in the data they receive. We give all the information for it not to be
an issue, they just need to make use of it.
More information about the dev