On Mon, Jun 9, 2008 at 5:41 PM, Stefan de Konink <[EMAIL PROTECTED]> wrote: > Tom Hughes schreef: >> In message <[EMAIL PROTECTED]> >> Stefan de Konink <[EMAIL PROTECTED]> wrote: >> >>>>>>> - Assures the client always get the id back >>>>>> That is already assured by the current API definition. >>>>> For 'updates' too? According to spec only an id is send after a create. >>>> Well you don't need it on an update as you already know the ID. >>> Not if you create a changeset with updates and creates. Should the >>> client maintain which object was a create and which one was an update? >>> Now that sounds like making it difficult for the clients, instead of >>> just returning all id's in the diff/changeset. >> >> Unsurprising the changeset spec addresses these issues. > > You mean this? > > When downloading data the client will receive a version number. This > number must be stored and provided when updating (or deleting); if it > does not match the server's current verision number at the time the > update/delete is made, the operation will fail. > > > I don't really see how changesets are going to address all changes at > the same time + returning version numbers. Since it is not an atomic > operation, how can one reliably getting these id's before a /close ?
Now you're confusing a changeset with the diff upload call. The diff upload call /is/ atomic. You can have multiple diff upload calls per changeset. The changeset spec in the 0.6 API includes all of this information. > > > Anyway it gets of the original point, which I would like to have solved > first. > I think it has been solved: just implement the API the way it is. Dave _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
