Well, a couple of questions.<br>- 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?<br>
- 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?<br><br>I've been happy using potlach so far - not sure why a new version is needed: any thread pointing this out anywhere?<br>
<br>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". <br><br><br>Beh.<br>
<br>Yann<br><br><br><div class="gmail_quote">On Fri, May 2, 2008 at 1:20 AM, Christopher Schmidt <<a href="mailto:crschmidt@metacarta.com">crschmidt@metacarta.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, May 02, 2008 at 12:24:35AM +0100, Tom Hughes wrote:<br>
> In message <<a href="mailto:16e8cf860805011406t29e3d382ke4b18ecf9fe92a4a@mail.gmail.com">16e8cf860805011406t29e3d382ke4b18ecf9fe92a4a@mail.gmail.com</a>><br>
> "Tom Carden" <<a href="mailto:tom@tom-carden.co.uk">tom@tom-carden.co.uk</a>> wrote:<br>
><br>
> > I think the fact that it has its own API is a much bigger concern than<br>
> > it being written in AS 1.0 is. If Potlatch was using the main API,<br>
> > development of API-backed features in Potlatch could be shared by<br>
> > other editors too. Any tests written for the API would help Potlatch.<br>
> > Any changes to the schema would only have to happen once. etc. etc.<br>
><br>
> I think most of us (with the possible exception of Richard) would<br>
> agree here.<br>
><br>
> Well actually I don't mind the existence of the AMF API as such so<br>
> long as it is just concerned with decoding the RPC calls and encoding<br>
> the results, and it uses the rails object model to do all the work<br>
> so that important code is shared with the XML API.<br>
<br>
</div>There's an important difference between this and "Potlatch using the<br>
main API".<br>
<br>
There are, I believe, some things that Potlatch can do that no<br>
other client can do, because the API to do it is not available.<br>
<br>
Specifically:<br>
* whichways_deleted gets deleted ways in a bbox, which the main API<br>
doesn't provide<br>
* getway_old has a "last deleted version", which seems different<br>
<br>
More problematic than the specific methods which do or don't exist,<br>
however, is the fact that the Potlatch way of interacting with them is<br>
*entirely* different -- so when a bug is fixed in the main API, the fix<br>
has to be duplicted in the Potlatch/amf_controller.<br>
<br>
This affects development of the server side APIs. You, at one point, put<br>
forward a significant amount of effort in improving the Rails code in<br>
amf_controller: that work benefited only Potlatch. If Potlatch was using<br>
the same backend rails calls (rather than just objects/models), then<br>
that development time could have benefited other clients as well.<br>
<br>
Potlatch has a very different way of interacting with the API. This way<br>
of interacting with the API has some benefits, and could allow for<br>
other clients similar to Potlatch to be developed without being tied<br>
explicitly to amf_controller, which is (at least at the moment)<br>
essentially Potlatch specific. (Things like 'masterscale' and<br>
'potlatch_lon' seem to be indicate this anyway: maybe I'm wrong here.)<br>
<br>
I don't know amf: I see from the code that it's Actionscript Message<br>
Format. If there is a desire for supporting Actionscript Message Format<br>
for API actions, I don't see a problem with that at all: In fact, other<br>
encodings of OSM data delivered via the API seem a natural progression<br>
to me. (I'm biased here, having done this with TileCache, FeatureServer,<br>
WPServer, etc.) But I don't see that that means that Potlatch should<br>
have access to API methods which simply don't exist to any not<br>
potlatch-clients (or that clients would have to speak the same language<br>
as Potlatch to use them).<br>
<div class="Ih2E3d"><br>
> We have in fact started moving towards that goal with some work<br>
> that Steve did on some of the AMF calls.<br>
<br>
</div>This is a different goal, that of replacing SQL with rails objects. A<br>
valuable goal, but not the same as abstracting the data selection calls<br>
to a single set of code, and then using that code to serve both the main<br>
API and amf_controller.<br>
<div class="Ih2E3d"><br>
> The problem is that it turned out that, even after I had optimised<br>
> the code, it is significantly slower to go through the rails object<br>
> model that to make direct SQL queries.<br>
<br>
</div>This is interesting, but (imho) less relevant: The value of the above is<br>
actually doubled by this statement, since if Potlatch and the API were<br>
using the same function, one could optimize this, and since the code is<br>
used by *all* clients (not just one) you would see any problems with SQL<br>
calls more generally, and perhaps find it easier to debug them. (I think<br>
this is compounded by the fact that AMF is a format which is hard to<br>
replicate outside of a flash client, which makes server side developers<br>
less likely to have the technical chops to debug them.) A common library<br>
for API functionality between amf_controller and the various<br>
api_controller methods would help resolve this to some extent.<br>
<div class="Ih2E3d"><br>
> I think even Richard wouldn't mind too much making the AMF API use<br>
> the rails object model if it wasn't for the performance issues.<br>
<br>
</div>Using the Rails Object Model is solving an *internal* API issue, but<br>
there still continue to exist two external APIs that use different<br>
backend data manipulation to achieve their goals. This seperation is<br>
what I see as more problematic -- and I think that's what Tom was<br>
addressing as well, though I could be wrong.<br>
<br>
Regards,<br>
<font color="#888888">--<br>
Christopher Schmidt<br>
MetaCarta<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev" target="_blank">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a><br>
</div></div></blockquote></div><br>