[josm-dev] josm-ng progress

[Frederik Ramm]

Hi,

> Here is how is it meant to work. Please look at it and try to find weak
> points where the scheme would broke.

There is one problem that JOSM currently has and that your design
doesn't solve - in fact I believe it is very hard or even impossible
to solve but I'll bring it to the table nonetheless.

When uploading data to the API, JOSM uploads nodes first, then ways,
then relations, and after that come the deletions. All this to avoid
"precondition failed" errors because you try to delete a node for
which you haven't yet uploaded the modified way that doesn't use it
any more, etc.

JOSM does not upload changes in the order you made them (because this
would probably cause an unnecessary amount of uploads for various
steps of your local edit history).

This is all fine, but every now and then uploading stops due to a
network failure or so. JOSM then clears the whole command/undo history
because logically the *changed elements* that have been uploaded are
something completely different from the *change actions* visible
there, and you have no chance to find out which actions have been
"uploaded" and which haven't (some might be partially uploaded even).

This freaks out many users because they think they have just lost
their edits. From a user perspective, they would much rather have JOSM
go through all their edits from earliest to latest and upload them; if
uploading stops, they know exactly where they are (and command history
would only be cleared up to the point where the upload stopped).

Maybe there is a way to determine which actions "supersede" others.
For example - I move node 1, then move node 2, then move node 1 again;
the first move would be superseded and it would not make sense to
upload it. If one could find a good implementation for this, then it
would be possible to key the uploading process to the command list
instead of the current scheme.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'