[OSM-dev] The future of Potlatch

[Christopher Schmidt]

On Fri, May 02, 2008 at 08:35:06AM +0100, Tom Hughes wrote:
> To summarise I think we both want the same thing, but you perhaps
> think somebody should just sit down and bang an AMF version of the
> current XML API and I'm happy with trying to incrementally move
> towards that position?

Well, I don't think that's how I would put it. I think you were slightly
oversimplifying when you just said "It's a few lines of Rails object
code." Some of the request methods in Potlatch are at least a bit more
complex than that. getway_old, for example, is slightly more complex
than that, as is putway.

I won't pretend that I know nearly as much about the rails code as you
do, but it seems like some of these would be better abstracted out. If
that were the case -- that is, that all the Rails code on the site used
the same underlying methods to talk to the database, given a 'fixed'
API, and amf_controller was just about encoding the returned data into
AMF -- then I thiink it would be possible to change the underlying slow
methods into SQL (after proper profiling), because the main reason not
to is 'maintaining two different codebases sucks', rather than 'no one
likes SQL over rails'.

The fact that Potlatch was using SQL was unfortunate, but for 
some problems, that could be the right solution. The fact that the API was
*not* was what I would see as the real problem -- and changing the
architecture so that that wouldn't happen for the same task seems
valuable to me, or at least heading in that direction.

Perhaps you were already heading there; I don't really know what the
plans are for rails_port development, so I'm probably off my rocker :)

Perhaps I'm wrong on this stuff: as I said, I'm new to the rails world.
At this point, putting my code where my mouth is is probably the right
choice, so until I sit down and hack on stuff, it's fine to ignore what
I'm saying :)

I'll see if I get time to have a play this weekend and improve my
knowledge and understanding of the code, and maybe I'll find that you're
right, and there's no reason to bother.

Regards,
-- 
Christopher Schmidt
MetaCarta