[OSM-dev] 0.6 API clarifications and corrections

[Frederik Ramm]

Hi,

> > Use your imagination then. If the user requests, say, a graphical 
> > representation of the changes effected by change set X, you will not 
> > want to show the intermediate steps. So you would have to collapse the 
> > change set - something changed first and deleted later, show it only as 
> > deleted; something created at position A and moved to position B, show 
> > it as created at position B; something moved from X to Y and then from Y 
> > to Z, show it as moved from X to Z.
> 
> It is trivial to do that kind of stuff on the clientside.

Not trivial, and a benefit for all if implemented server-side.

> First of you might want to do rollback from Z to Y only because
> you want to keep Y to X.

Changesets are a grouping of edits that make things easier because one
only has to work with the groups - e.g. not show all individual edits,
but show the group as a whole, etc.

A changeset can only be rolled back as a whole. The rollback of a
changeset leads to a new, "inverted" changeset that should be tagged
in a way to express the fact that it is a rollback of changeset X.

If you want to do partial rollbacks, then you don't need changesets at
all - you might as well go with the already implemented "restore
historic version" function in Potlatch. 

In that case you lose the changeset being rolled back - you do "some
changes" but you don't do a "rollback of a changeset".

It is fully ok for clients to use the history of individual objects to
return them to any state they were in at some time before, like
Potlatch does, but this has nothing to do with rolling back
changesets.

I'm a bit tired of this. I understand that you're unhappy about not
having been at the hack-a-thon but can we perhaps now proceed with the
work at hand instead of making an endlessley protracted discussion
about every single aspect of the new API. (The longer this goes on,
the more reason there is for those that will one day do 0.7 to *not*
discuss things on the lists, citing this discussion as an example that
nothing good comes of it.) Rollback and the retrieval of changeset
data aren't even on the critical path, they can be implemented at
*any* *later* *time* without changing the API. We don't have to find a
solution today.

You want changesets as some universal access and documentation method
for the history of everything, and I want them as closed, near-atomic
changes. I'd say the person who codes it gets to decide, but as I
said, it doesn't even have to be decided now.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"