[OSM-dev] Structured error messages from API
ian.dees at gmail.com
Thu Dec 10 17:50:12 GMT 2009
On Thu, Dec 10, 2009 at 11:39 AM, Ævar Arnfjörð Bjarmason
<avarab at gmail.com>wrote:
> On Thu, Dec 10, 2009 at 17:25, Karl Guggisberg
> <karl.guggisberg at guggis.ch> wrote:
> >> 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:
> Indeed, but I understood it from Ian's post "when doing a[sic]
> osmChange upload" that he was only interested in step #1.
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.
> > 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
> Actually when I do uploads uploading the file itself and processing on
> the server seems to take around the same time, judging from network
> sniffing I've done. Results may vary though.
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.
> > 2. process on the server - this takes most of the time, no feedback here
> Yup, PostgreSQL can't tell you where it's at in the query:
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.
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
> > 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.
> I've filed a bug to track this, for what it's worth:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev