<div class="gmail_quote">On Thu, Dec 10, 2009 at 10:55 AM, Ævar Arnfjörð Bjarmason <span dir="ltr"><<a href="mailto:avarab@gmail.com">avarab@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Thu, Dec 10, 2009 at 16:20, Ian Dees <<a href="mailto:ian.dees@gmail.com">ian.dees@gmail.com</a>> wrote:<br>
> On Thu, Dec 10, 2009 at 10:16 AM, Matthias Julius <<a href="mailto:lists@julius-net.net">lists@julius-net.net</a>><br>
> wrote:<br>
>><br>
>> There are requests in JOSM's trac to improve the handling of API<br>
>> errors.  To do that JOSM needs to get a better understanding on what<br>
>> is wrong with the data.<br>
>><br>
>> Currently, JOSM is parsing the error strings the API is returning.<br>
>> This is far from ideal because they are not structured, not documented<br>
>> and might change without warning.<br>
>><br>
>> To improve things I would like to see the API extended to return meta<br>
>> data about errors (error type, id of offending element, ...) in a<br>
>> structured way.  There are a couple of ways to that (that came to my<br>
>> mind):<br>
>><br>
>> - change the Error header<br>
>> - add home-made HTTP headers (X-Error-Type ...)<br>
>> - add pseudo headers to the body<br>
>> - return a XML document containing all the info<br>
>><br>
>> (see also <a href="http://trac.openstreetmap.org/ticket/2544" target="_blank">http://trac.openstreetmap.org/ticket/2544</a>)<br>
>><br>
>> What do you think?<br>
>><br>
>> How important is that to people on the receiving end (application<br>
>> developers)?<br>
>><br>
><br>
> On a related note, I would be very interested in seeing a progress of some<br>
> kind being returned when doing a osmChange upload. I realize that it is<br>
> difficult (because it could fail after spitting out lots of seemingly valid<br>
> IDs), but if it was documented it would be doable.<br>
<br>
</div></div>You mean showing upload progress in JOSM as opposed to the current<br>
cylon impression? That could be implemented by counting the number of<br>
bytes of the osmChange request that have been successfully sent over<br>
the wire. That's how upload progress bars are usually implemented.<br>
<br>
Obviously the upload could fail but that's another issue.<br>
</blockquote></div><br>The number of bytes uploaded != the progress of the changeset upload process (although it's better than what's there now). I'm assuming the server reads the entire file to memory of some sort before parsing the XML and applying changes to the database? If so, the upload of the osmc file could happen in a few seconds but it could then take lots more time for the server to apply the changeset. At that point, the tool will only be able to block until it times out or receives a response from the server.<br>