On Fri, May 02, 2008 at 12:24:35AM +0100, Tom Hughes wrote: > In message <[EMAIL PROTECTED]> > "Tom Carden" <[EMAIL PROTECTED]> 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 _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk