[OSM-dev] 0.6 api - one more time

Christopher Schmidt crschmidt at metacarta.com
Mon May 5 15:48:51 BST 2008


On Mon, May 05, 2008 at 02:44:02PM +0200, Martijn van Oosterhout wrote:
> I for one am pretty happy with all these changes, they represent a
> great step forward for the project and will open up many interesting
> possibilites for the future.

So, one thing that I would like to question is whether we really need to
break backwars compatibility for this change at all.

Based on my reading, there is only one aspect of the changes in the API
that forces backwards incompabitibility: the requirement for the client
to generate a changeset before uploading and provide that changeset
identifier.

Now, based on my reading of this, (which could be wrong), if that's the
only change, there is a way to simply allow 0.5 API clients continue to
work: If a changeset identifier is not provided, then create a changeset
automatically. 

If this was done, clients wouldn't need to change their behavior right
away: instead, there could be a gradual transition for all users to
download new clients, fix tools, etc. etc.

If this were done, there would be two options for determining when to
create a new changeset: 
 * Create a new changeset for every edit. Ugly, easy.
 * Create a new changeset hueristically: When an object with no
   changeset is uploaded, check the open changesets for that user, find
   one which was automatically created, and if it was touched within the
   past, say, hour, then keep using it -- otherwise, automatically open
   a new changeset.

I understand that there is a strong reason to 'force' users to go to an
updated client, but there are (in my mind) some strong reasons for
supporting backwards compatibility. The "JOSM in Debian - web API
stability" thread here:

http://lists.alioth.debian.org/pipermail/pkg-grass-general/2008-April/thread.html

Expresses concerns over API stability. In the past, I had done my best
to explain that backwards compatible API changes are given significant
weight in the community, but this change would kinda shoot that argument
in the foot :)

Currently, JOSM is not planned to be included in the next release
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474632) for exactly
this reason.

If my reading is correct, allowing backwards compatibility would be
fairly easy, codewise. It would be my hope that this would allow for
easier transitioning for things like JOSM-in-Debian: it would allow
backported versions of JOSM to filter in and fill the need of allowing
changesets without breaking the existing installed editor base. 

I'm happy to look into code here, if that's an issue, but I think this
is much more a social than technical question, and I'm hopeful that
other people can offer their opinions.

Regards,
-- 
Christopher Schmidt
MetaCarta




More information about the dev mailing list