On 10 July 2017 at 10:48, Frederik Ramm <frede...@remote.org> wrote: > Hi, > > On 10.07.2017 11:14, Andy Allan wrote: >> My intentions for the next few months are to continue to >> do whatever I can to encourage new contributors. > > I think it would be helpful for new contributors if the following two > points could be explained: > > * What kinds of changes to the API are acceptable while still being "API > 0.6"? Is anything that adds new API calls automatically on hold until we > do "0.7", or should we just refrain from breaking existing API calls?
As far as I'm concerned, adding new API calls to the non-core parts of the API are fine. So e.g. DiaryEntries or Notes but avoiding nodes/ways/relations/changesets etc. For those, I'm also personally fine with adding new APIs, but I know that others prefer for them to go into cgimap at the same time. But see also below. For 0.6 there should be no breakage of existing API calls, of course. I know people expect big things from 0.7, but I'd be happy to see a 0.7 release that doesn't change any data models, but fixes the API. The API for notes is pretty bad, for example[1]. We could have 0.7 as an interim API that runs in parallel with 0.6 for a year or two, and save the big changes for 0.8. > Maybe this is even on some mental roadmap somewhere - I heard people > talking about making the web site actually *use* API calls, rather than > accessing the database directly. I have many mental roadmaps, but there's a line to be drawn between long-term personal roadmaps and astronautism :-) > * What is the relationship between "cgimap" and the web site, and in how > far are contributions that touch an area handled by "cgimap" required to > cover both the C++ and the Rails implementation? Currently they work in parallel. So everything that is in cgimap has a corresponding ruby version that's not used in production for OSMF (but is probably used elsewhere in production). More calls are gradually being added to cgimap - originally it only handled the map call, hence the name. You can get a feel for the current state by looking at which calls are passed to cgimap[2] by apache, the rest are handled by openstreetmap-website. I would like to change this situation, by using the cgimap-ruby gem[3]. This would allow us to use cgimap within openstreetmap-website, and get rid of the corresponding ruby code. This would be useful for development and self-deployments, even if those paths are still bypassed in production and still handled by a standalone cgimap process. It would also mean anything added to cgimap wouldn't need a corresponding ruby version. It would also mean that there is less pressure to add more and more API endpoints to cgimap, and instead only add those that are necessary from a performance point of view. There is a slight difference of opinion on whether we should use cgimap for every API call at some point in the future. I don't think it's worthwhile and I think the C++ code should only be for performance-critical things, but opinions vary. > One reason why this is of interest to me is that I'm still very much > interested in being able to access deleted objects through the API and > through the web site. I've made a few half-baked attemtps at > implementing that in the past > (https://github.com/woodpeck/openstreetmap-cgimap/tree/deleted_call, > https://github.com/woodpeck/openstreetmap-website/tree/browse-deleted-objects) > and would appreciate guidance of how to "do this right", if at all > possible within the constraints of "0.6". So there's already the AMF API, as I know you're aware but others might not be. For the deleted items map call, it's apparently very inefficient, and there have been plans to "do it properly" for as long as I can remember. However, I don't see why porting the deleted items map call to to the XML API should have to wait indefinitely, so I'd definitely support that. Not least because we could then consider turning off the AMF api, which is awesome but gnarly code to maintain. Thanks, Andy [1] "POST /api/0.6/notes/addPOIexec" for example, see https://github.com/openstreetmap/openstreetmap-website/blob/39c5d8caa71b29d70bb136d6e0a560426e089112/config/routes.rb#L102-L106 [2] https://github.com/openstreetmap/chef/blob/7720e35c56ebf155de90facca5a421e43974774b/cookbooks/web/templates/default/apache.backend.erb#L66-L75 [3] https://github.com/zerebubuth/cgimap-ruby _______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
