[OSM-dev] The future of Potlatch
yann.hamon at gmail.com
Fri May 2 03:09:55 BST 2008
Well, a couple of questions.
- Is cloudmade the same company with which SteveC tried to put advertising
on openstreetmap a year ago, putting it online without asking anybody
before, arguing it was because of money issue which proved wrong after a
couple of weeks?
- Is this flash applet going to be opensource, and made available for
development to the community, or closed source, giving that company control
over openstreetmap and the way data gets entered?
I've been happy using potlach so far - not sure why a new version is needed:
any thread pointing this out anywhere?
You get the idea. Imho stevec is trying to turn osm into his commercial game
*again*, and to be honest it's quite tiring. Oh right, but "openstreetmap
ain t communists like wikipedia".
On Fri, May 2, 2008 at 1:20 AM, Christopher Schmidt <crschmidt at metacarta.com>
> 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.
> * 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.
> Christopher Schmidt
> dev mailing list
> dev at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev