On Tue, Jan 13, 2009 at 1:53 PM, Richard Fairhurst <rich...@systemed.net> wrote: > Matt Amos wrote: >> in which case we're trading development effort for performance. >> i think we're operating in areas constrained by the lack of >> available developers, so making the barrier to entry higher is a >> tough decision. > > (Speaking seriously for once...) > > Kind of, but it's not a simple trade-off. Certainly as far as Potlatch is > concerned, server performance issues require development effort on the > client. The problem that's been brought up both here and on talk, where the > server dies halfway through a write operation and leaves the database in an > inconsistent state, is an example of this - there are others.
these problems are not due to rails - most are due to the lack of transactions, which is an implementation problem, and the many others are version race conditions, which is an API design problem. lets not confuse a performance issue with a bug or correctness issue. > When TomH did the quadtile stuff, that added a degree of complexity for a > boost in performance. I doubt anyone now would say it was the wrong > decision. absolutely, but i'd say that was a small increase in complexity in a small corner of the code (which is well hidden) for a large boost in performance. i'm sorry if i gave the impression i was totally against any form of increased complexity, because i'm not. i just think these things need to be balanced on a case by case basis. in the case of quadtile, i think the extra complexity was worthwhile. in the case of SQL in the amf_controller, i'm not so sure. this is just my opinion. cheers, matt _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
