[OSM-dev] GSoC API mentoring help needed

Paul Norman penorman at mac.com
Tue Feb 21 09:06:28 UTC 2017

On 2/20/2017 12:19 AM, Andy Allan wrote:
> I can see the purpose of this, but I've never seen it as being as high
> a priority as other developers do.

For me the concerns all stem from code duplication, principally leading 
to more optimization work on one path, so cgimap is much faster than 
browse pages. You can see a good example of this with relation history 
pages that time out while the cgimap powered API call is much faster.

I do consider this less important than my other API proposals, but I 
have students interested in it

> For example, I can see why the
> browse pages shouldn't have access to the data in a manner that's not
> exposed in the API, but that to me suggests improving the API, rather
> than forcing a lowest-common-denominator approach of forcing the
> browse pages to use the API.

I'm not advocating reducing the functionality of the browse pages. Part 
of the work with this is identifying what is lacking in the API. I hope 
to propose a new call to start the discussion before GSoC.

> I would avoid the pure-javascript approach, as it's just rewriting for
> the sake of rewriting. My suggestion would be to just change the
> existing browse pages code slightly - the controllers should make
> (internal) calls to the API endpoints, to replace their direct db
> access. Even better if those internal API calls are processed by
> cgimap-ruby!

As I see it, either way accomplishes the goal of having the requests for 
object information go through a common path and come with tradeoffs.

More information about the dev mailing list