[OSM-dev] 0.6 API clarifications and corrections

[Christopher Schmidt]

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 ->
new_version".

> > 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
mistake.)

Regards,
-- 
Christopher Schmidt
MetaCarta