[OSM-dev] "Deep History" App
zerebubuth at gmail.com
Wed Sep 16 12:23:09 BST 2009
On Wed, Sep 16, 2009 at 10:23 AM, Richard Fairhurst
<richard at systemed.net> wrote:
> Tom Hughes wrote:
>> BTW do not code anything new that uses amf_controller - anything
>> which is can currently do that the XML API can't will have to be added
>> to the XML API for Potlatch 2 anyway as AMF controller will be going
>> away at that point.
> Gah, Nabble ate my first reply to this.
> Assuming Potlatch 2 doesn’t have a live editing mode (and I don’t have any
> plans to code one) then it won’t need the AMF writes nor the more esoteric
> reads, as discussed here. It will be good to see these in the XML API.
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.
there's been a case of this before; too many map calls were slowing
the server and the solution was to use an optimised, read-only set of
mirrors (e.g: TRAPI, ROMA, etc...). once we've got a set of full
history diffs on the services server, maybe someone wants to write a
THRAPI or ROHA?
> However, the speed improvements in a live-panning editor still make the
> whichways, getway and getrelation calls worthwhile. Each of these is trivial
> in code size and maintenance: getrelation, for example, is one line with an
> error wrapper around it.
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 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.
supporting multiple formats may require changes in the API, so we
might need a 0.7. hopefully not...
whichever way it's done -- please! -- let's do it properly. i've had
enough of tracking down problems because different APIs acted in
different ways, and i'm sure everyone else has too.
> The other issue is retaining Potlatch 1.x as an option, even assuming
> feature parity between 1 and 2, given that Gnash does not yet support
> ActionScript 3 (or, rather, AVM2) and XML support in AS1 is very poor.
potlatch 3 in silverlight ftw? ;-)
More information about the dev