[OSM-dev] 0.6 API clarifications and corrections
crschmidt at metacarta.com
Thu May 15 12:18:30 BST 2008
On Thu, May 15, 2008 at 11:42:03AM +0200, bvh wrote:
> On Thu, May 15, 2008 at 11:31:13AM +0200, Frederik Ramm wrote:
> > >> Under the current plan, yes. We didn't think it was reasonable to
> > >> push that assumption down to the clients thought.
> > > Why would that be unreasonable? In what (futuristic) scenario would
> > > version numbers not increment monotonically one by one?
> > In the current scenario, you are basically not allowed to upload a new
> > version of an object if you haven't got the previous version.
> > This is unnecessarily strict.
> > For example, two people could download version 1 of a node; one adds the
> > foo tag, another adds the bar tag, both upload. With the plans for API
> > 0.6, one of the uploads will simply fail.
> > In theory, both uploads could be accepted without conflict, and we would
> > then have one change that goes from v1 to v2, and one change that goes
> > from v1 to v3.
> But one of them will be accepted first and the other will later
> be judged as sufficiently different, right? So the actually history
> in the database will have two transitions, one from v1 to v2 and
> the other from v2 to v3.
Yes, but the client uploaded version="1", and the server handed back
version="3". The client couldn't assume that "current_version + 1 ->
> > It is also possible to change the same object multiple times within the
> > same changeset, so one single changeset might catapult the object
> > version from 1 to 15.
> Wouldn't it be better then to just throw away consecutive changes to
> the same object and only keep the last one within each diff?
This is about changeset serialization, not diffs. (I made the same
More information about the dev