<div class="gmail_quote">On Thu, Dec 10, 2009 at 11:39 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 class="im">On Thu, Dec 10, 2009 at 17:25, Karl Guggisberg<br>
<<a href="mailto:karl.guggisberg@guggis.ch">karl.guggisberg@guggis.ch</a>> wrote:<br>
>> You mean showing upload progress in JOSM as opposed to the current cylon impression? That could be implemented by counting the number<br>
>> of bytes of the osmChange request that have been successfully sent over the wire. That's how upload progress bars are usually implemented.<br>
><br>
> It's not the upload or download which takes most of the time but the processing on the server.<br>
> Uploading an osmChange has three phases:<br>
<br>
</div>Indeed, but I understood it from Ian's post "when doing a[sic]<br>
osmChange upload" that he was only interested in step #1.<br></blockquote><div><br>My interest is in getting feedback from the API as it applies large changesets, so I'm mostly interested in #2 as the actual HTTP POST of the data file is a relatively small part of the transaction.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> 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<br>
<br>
</div>Actually when I do uploads uploading the file itself and processing on<br>
the server seems to take around the same time, judging from network<br>
sniffing I've done. Results may vary though.<br></blockquote><div><br>When uploading large diffs (changeset reverts, new data imports), time spent sending the data over the network is insignificant compared to the time spent applying to the server.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> 2. process on the server - this takes most of the time, no feedback here<br>
<br>
</div>Yup, PostgreSQL can't tell you where it's at in the query:<br>
<a href="http://wiki.postgresql.org/wiki/Query_progress_indication" target="_blank">http://wiki.postgresql.org/wiki/Query_progress_indication</a><br></blockquote><div><br>Presumably the API server performs many SQL queries to update the database, so the API application could provide feedback as it goes through the steps of updating based on the changeset.<br>
<br>Someone (sorry my shortterm memory is pretty crummy) pointed out that this would probably break the API's current error system as the server would no longer be able to send error headers once it starts sending streaming response information.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> 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<br>
><br>
> Actually, I implemented something based on the approach Avar proposes but I wasn't satisfied and didn't check it in.<br>
<br>
</div>I've filed a bug to track this, for what it's worth:<br>
<a href="http://josm.openstreetmap.de/ticket/4145" target="_blank">http://josm.openstreetmap.de/ticket/4145</a><br></blockquote></div>