[OSM-dev] The future of Potlatch

Christopher Schmidt crschmidt at metacarta.com
Fri May 2 01:20:05 BST 2008


On Fri, May 02, 2008 at 12:24:35AM +0100, Tom Hughes wrote:
> In message <16e8cf860805011406t29e3d382ke4b18ecf9fe92a4a at mail.gmail.com>
>           "Tom Carden" <tom at tom-carden.co.uk> wrote:
> 
> > I think the fact that it has its own API is a much bigger concern than
> > it being written in AS 1.0 is.  If Potlatch was using the main API,
> > development of API-backed features in Potlatch could be shared by
> > other editors too.  Any tests written for the API would help Potlatch.
> >  Any changes to the schema would only have to happen once. etc. etc.
> 
> I think most of us (with the possible exception of Richard) would
> agree here.
> 
> Well actually I don't mind the existence of the AMF API as such so
> long as it is just concerned with decoding the RPC calls and encoding
> the results, and it uses the rails object model to do all the work
> so that important code is shared with the XML API.

There's an important difference between this and "Potlatch using the
main API".

There are, I believe, some things that Potlatch can do that no
other client can do, because the API to do it is not available.

Specifically:
 * whichways_deleted gets deleted ways in a bbox, which the main API
   doesn't provide
 * getway_old has a "last deleted version", which seems different

More problematic than the specific methods which do or don't exist,
however, is the fact that the Potlatch way of interacting with them is
*entirely* different -- so when a bug is fixed in the main API, the fix
has to be duplicted in the Potlatch/amf_controller.

This affects development of the server side APIs. You, at one point, put
forward a significant amount of effort in improving the Rails code in
amf_controller: that work benefited only Potlatch. If Potlatch was using
the same backend rails calls (rather than just objects/models), then
that development time could have benefited other clients as well.

Potlatch has a very different way of interacting with the API. This way
of interacting with the API has some benefits, and could allow for
other clients similar to Potlatch to be developed without being tied
explicitly to amf_controller, which is (at least at the moment)
essentially Potlatch specific. (Things like 'masterscale' and
'potlatch_lon' seem to be indicate this anyway: maybe I'm wrong here.)

I don't know amf: I see from the code that it's Actionscript Message
Format. If there is a desire for supporting Actionscript Message Format 
for API actions, I don't see a problem with that at all: In fact, other
encodings of OSM data delivered via the API seem a natural progression
to me. (I'm biased here, having done this with TileCache, FeatureServer,
WPServer, etc.) But I don't see that that means that Potlatch should
have access to API methods which simply don't exist to any not
potlatch-clients (or that clients would have to speak the same language
as Potlatch to use them).

> We have in fact started moving towards that goal with some work
> that Steve did on some of the AMF calls.

This is a different goal, that of replacing SQL with rails objects. A
valuable goal, but not the same as abstracting the data selection calls
to a single set of code, and then using that code to serve both the main
API and amf_controller.

> The problem is that it turned out that, even after I had optimised
> the code, it is significantly slower to go through the rails object
> model that to make direct SQL queries.

This is interesting, but (imho) less relevant: The value of the above is
actually doubled by this statement, since if Potlatch and the API were
using the same function, one could optimize this, and since the code is
used by *all* clients (not just one) you would see any problems with SQL
calls more generally, and perhaps find it easier to debug them. (I think
this is compounded by the fact that AMF is a format which is hard to
replicate outside of a flash client, which makes server side developers
less likely to have the technical chops to debug them.) A common library
for API functionality between amf_controller and the various
api_controller methods would help resolve this to some extent.

> I think even Richard wouldn't mind too much making the AMF API use
> the rails object model if it wasn't for the performance issues.

Using the Rails Object Model is solving an *internal* API issue, but
there still continue to exist two external APIs that use different
backend data manipulation to achieve their goals. This seperation is
what I see as more problematic -- and I think that's what Tom was
addressing as well, though I could be wrong. 

Regards,
-- 
Christopher Schmidt
MetaCarta




More information about the dev mailing list