> You mean showing upload progress in JOSM as opposed to the current cylon > impression? That could be implemented by counting the number > of bytes of the osmChange request that have been successfully sent over the > wire. That's how upload progress bars are usually implemented.
It's not the upload or download which takes most of the time but the processing on the server. Uploading an osmChange has three phases: 1. upload the osmChange document - can take some time, we could give feedback information based on the bytes sent, but can be neglected compared to phase 2 2. process on the server - this takes most of the time, no feedback here 3. download the diffResult - can be neglected compared to phase 2. Again, we could give feedback based on the bytes read from the server, but it's not worth the effort Actually, I implemented something based on the approach Avar proposes but I wasn't satisfied and didn't check it in. Regards Karl -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Ævar Arnfjörð Bjarmason Gesendet: Donnerstag, 10. Dezember 2009 17:55 An: Ian Dees Cc: [email protected] Betreff: Re: [OSM-dev] Structured error messages from API On Thu, Dec 10, 2009 at 16:20, Ian Dees <[email protected]> wrote: > On Thu, Dec 10, 2009 at 10:16 AM, Matthias Julius > <[email protected]> > wrote: >> >> There are requests in JOSM's trac to improve the handling of API >> errors. To do that JOSM needs to get a better understanding on what >> is wrong with the data. >> >> Currently, JOSM is parsing the error strings the API is returning. >> This is far from ideal because they are not structured, not >> documented and might change without warning. >> >> To improve things I would like to see the API extended to return meta >> data about errors (error type, id of offending element, ...) in a >> structured way. There are a couple of ways to that (that came to my >> mind): >> >> - change the Error header >> - add home-made HTTP headers (X-Error-Type ...) >> - add pseudo headers to the body >> - return a XML document containing all the info >> >> (see also http://trac.openstreetmap.org/ticket/2544) >> >> What do you think? >> >> How important is that to people on the receiving end (application >> developers)? >> > > On a related note, I would be very interested in seeing a progress of > some kind being returned when doing a osmChange upload. I realize that > it is difficult (because it could fail after spitting out lots of > seemingly valid IDs), but if it was documented it would be doable. You mean showing upload progress in JOSM as opposed to the current cylon impression? That could be implemented by counting the number of bytes of the osmChange request that have been successfully sent over the wire. That's how upload progress bars are usually implemented. Obviously the upload could fail but that's another issue. _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
