[OSM-dev] Applet progress..

Immanuel Scholz immanuel.scholz at gmx.de
Thu Feb 23 21:54:47 GMT 2006


Hi,

to do a bit of "fishing for compliments" ;-) and also to call for testing
help, I'll like to tell you what I have changed today in the applet.


I rewrote the way, the applet uploads the data to the osm server. In the
old way, everything the user changed launched a new thread which tries to
upload exactly this change and then quit.

There were several flaws with this system:
- It is possible for an action to get uploaded before some older make it
to the server, although the newly may depend on the older to be executed
first. As example quickly adding two nodes and a line segment between them
could first upload the line segment (with illegal, randomized node-ids)
and later  the nodes (which could even fail to upload for some reason).

- If an action fails, the newer actions that may depend on this action get
executed anyway. Since the creation of new objects yield in random numbers
as the id, this could lead to wrong data. This is believed to be the
problem, where some line segments surprisingly span hundrets of miles from
scandinavia to africa ;-).

- In case of failed actions, the action did not properly reset the data to
the old state but hope for a periodical background thread to update the
data (or the angry user reload the applet). This decreased the
responsivness of the applet in case of server problems. Even worse, if the
user does changes before the background thread correct the intern
database, this could lead to some strange problems as example connecting a
line segment to an node, that does not exist. This is believed to be the
bug of the vanishing-line-segments-trac item 99.



So now, all commands that need to be uploaded to the server are executed
in one thread, one after another. The new class CommandManager does the
schedules. OsmApplet enqueue new commands to the schedule while an
background thread executes them in a FIFO queue.

If a command fails, the whole queue will be aborted. Although this sounds
terrible, it is the only right thing to do :-(. (Okok.. an dependency
analysis could be done to only abort commands, that depend on the failed
one. This sounds more complicated than it is - just every command has to
know which objects it operates on and then a bit of collection comparing
is needed. I will do it in my next coding fewer ;)

Additional to the only one thread, every modification to the internal data
is done in the main thread (the applet runs in). This will hopefully
reduce some possible (but unlikly) problems with concurrent modifications
which in turn could do very strange things to the applet. (This process
isn't done yet, there is an thread left which modifies the intern data..)

As a bonus, an text "uploading..." is displayed at bottom right as long as
there are some commands in the queue, so the user get a quick feedback not
to close his browser too quickly after doing something (or in other words:
now the user knows when it is safe to close the browser ;)


DO TESTING! If you have an developer account, please test the applet
there. I did some testing here, but now I have to go off to bed and will
not be available for testing until probably monday (But I will answer
mails this weekend ;).

Ciao, Imi.






More information about the dev mailing list