Matt Amos wrote: > let's please try and avoid API bloat. as tom said, there are already > history calls in the api which give enough information for the client > to reconstruct all geometries of a way (at least as well as the server > can, at any rate). > > these APIs are open for everyone to use, with the caveat that our > admin team might have to stop accesses if the server performance > starts to hurt people's editing activity. the server is there > primarily for editing.
Indeed. Recovering previous versions is an important part of editing, and the timestamp-based download is a simple interface to that. In this scenario, the AMF history methods are a significantly more efficient way of extracting the data from the db than repeated interrogations of the XML history calls, so the impact on server performance is less. But ultimately, how the call works behind the scenes, and indeed whether it hits the main OSM server or another one, is really just a detail. > it would be nice to have the API operate in several different > formats, for reading and writing. many people have asked > for a json API, you want ^W have > an AMF API, maybe it's possible to write a PB/Thrift API (for > teh speedz). for this, we need to do some work (possibly a lot > of work) to divorce the presentation layer format code from > the API logic code. I've never understood, though I'm an utter n00b at all of this, why there's so much XML-specific code in our controllers. Shouldn't the controller send the data out to the view, and the view render it as XML (or AMF, or JSON, or the HTML data browser)? But doubtless you fancy 21st century programming guys are laughing at my naivety here. :) cheers Richard -- View this message in context: http://www.nabble.com/%22Deep-History%22-App-tp25458674p25470787.html Sent from the OpenStreetMap - Dev mailing list archive at Nabble.com. _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
