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 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
