[OSM-dev] 0.6 API clarifications and corrections

bvh bvh-osm at irule.be
Fri May 16 08:40:40 BST 2008

On Fri, May 16, 2008 at 10:18:38AM +0200, Frederik Ramm wrote:
> 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.

Huh? There is currently no software that can create changesets
let alone roll them back. So we don't know yet if they can only be
rolled back as a whole.

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

You want the changeset to limit the scope of what you are going to
rollback. But within that scope I think in the end we will end up
with both -try to rollback everything- and -try to rollback
anything that fits these and these criteria-

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

That is totally dishonest. You say you are tired but still want to
get in your last word. On top you imply I hold some kind of grudge,
which I dont. My interest in this discussion is that I am
implementing the thing from the client side. Just like Christopher
because he needs to implement something on the server side. 
Going forward we stumble upon questions that have insufficiently
been answered and we ask them here. When (some of) the 
answers are totally out of sync with the documentation
I seek clarification. That is why I am in this thread.

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

If you are so agnostic about it all, why are you in this thread? 

cu bart

More information about the dev mailing list