On 10 July 2017 at 13:25, Matthijs Melissen <i...@matthijsmelissen.nl> wrote: > On 10 July 2017 at 11:14, Andy Allan <gravityst...@gmail.com> wrote: >> Thanks Tom. My intentions for the next few months are to continue to >> do whatever I can to encourage new contributors. I've done a lot of >> refactoring recently which will help whoever tries to make code >> changes, but there's other things I think I can do too. > > Currently, the openstreetmap-website is both responsible for the > openstreetmap.org web application, and for the API. > > How hard would it be to separate these two functions, perhaps even > into two projects?
It's not hard, but I personally think it's not worthwhile. But as I said in my response to Frederik, opinions vary and other core OSM developers will disagree with me. I'll give some counterpoints to your statements: > Would there be any advantages in doing so? Intuitively both functions > seem to be separate projects. I don't see them as being different at all. If you want to "view a way" or "view a diary entry", then there's a choice of output formats - XML, html or json (in the future, perhaps). So one app can easily have three different views, rather than having an entirely different application just to change the display format. Our API currently covers only a small part of the function of the website. In future we could allow you to post diary entries via the API, or add new friends, or get a list of comments on your diary entries. Again, it would seem strange to me to have a rails app that lets you view your list of friends as a webpage, but then need a different app running to see that same list in json or XML. > I could imagine having two smaller > applications might make maintenance easier. Or it would spread the developers thinner, and lead to a lot of duplicated effort. > It would also mean we > could, for example phase Ruby out for the app but not for the api or > vice versa. I'd rather phase out low-level code like C++! Even better, we can also phase out home-grown ruby code and use third-party libraries much more often. There's very little about what we do that needs anything special, beyond the map call. Most of OpenStreetMap is completely routine things like signing up, resetting passwords, CRUD on simple objects and RESTful API calls. And we don't even do much of that - we're not dealing with millions of requests per second or anything like that. So the less code we have of our own to maintain, the better, and the higher-level language it can be written in the better, as far as I'm concerned. > Lastly, making the website make only use of well-defined > api endpoints instead of interface with the database directly might > also makes things clearer. I've said similar things in the past, but I realise different developers have said similar meaning slightly different things. For me, that means that we should unify the internals of the rails port (e.g. not having a separate "BrowseController" for viewing a way, and a different "WayController" for viewing a way in XML). For other developers it means changing the rails port to make API calls (e.g. BrowseController would fire off HTTP calls). For other other developers it means turning the browse html pages into a javascript SPA that fire off http calls to the API for the data it needs. I'm not in favour of 2 and 3. > Have there been any thoughts in this direction? There's been many thoughts over the years, but nowhere near enough implementation! Thanks, Andy _______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
