[OSM-dev] "Deep History" App
zerebubuth at gmail.com
Wed Sep 16 13:32:28 BST 2009
On Wed, Sep 16, 2009 at 12:51 PM, Richard Fairhurst
<richard at systemed.net> wrote:
> 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.
> 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.
on the other hand, they're also a significantly more complex
(server-side) way of extracting that data. i don't know of any
measurements of server performance, so i can't comment on the impact.
> 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.
until someone starts hitting the server too much - and then it becomes
very, very important ;-)
>> 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
^W a *proper* ;-)
>> 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)?
yes*. but there's also the parsing to be done and that's not quite so simple.
> But doubtless you fancy 21st century programming
> guys are laughing at my naivety here. :)
no - i'm joining you in the naivety. the API should do it that way;
there should be (almost) orthogonality between the logic and
presentation layers. it should be easy to add new formats for reading
*and* for writing.
but -- and this is important -- they should all be the same "API"
(barring the format-dependent details) taking the same arguments and
returning the same results.
*: as tom just pointed out, there are performance issues which prevent
us from using the rails xml builder functionality. although, it has to
be said, this functionality was added in rails after the rails_port
was originally written.
More information about the dev