On Tue, Jan 13, 2009 at 12:17 PM, Frederik Ramm <frede...@remote.org> wrote: > One is talking to users - letting them register, write blogs, write > messages (and if the trend continues, one day they'll be able to upload > images, have multi-page user profiles and forums and a full-blown E-Mail > system all within OSM).
maybe we should just bow to the inevitable and re-write OSM as a facebook app :-P > This is > the part where a Rails-like system excels, but it is not in any way > mission critical for us and could also be done in a scripting language > or web templating system of your choice. arguably user logins are pretty critical, but i get your point. > here, the API is actually just a rather thin > REST layer on top of the database. a large amount of the work done in the rails layer when writing is validation and the rails validations are a nice way of doing that. > And this is where, in my eyes, the > whole Rails migrations and ActiveRecord automatism is of no use at all > and is in fact circumvented more than it is used. This part should > probably be separated from the rest and implemented in an old-fashioned > compiled language. certainly for things like the map call the rails machinery is not very useful. i would agree that, at some point in the future, we'd like to move as much of the logic and constraints of the API into the database and use things like triggers to handle updating the history tables. there are downsides to this approach as well. for example, in an old-fashioned compiled language it would have taken much longer to generalise the database backend to both mysql and postgres (and the barrier to entry would have been higher). yes, yes, i know if it were designed "properly" it would have been database agnostic from the beginning. what do you see as the benefits of an old-fashioned compiled language (presumably you mean C/C++/Java) over just plain ruby? just because we're using ruby doesn't mean we have to use rails+activerecord :-) > In my eyes, OSM is not a "typical Rails project", nor even a project > where Rails can demonstrate superiority to anything else. In parts, OSM > is even a "we're Rails here but it's really not optimal" project. there are many kinds of optimality. in this case i think the brevity, readability and testability of the API code is improved by adopting rails-isms, even though they're not a perfect fit to the kinds of things we're trying to do. cheers, matt _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
