[OSM-dev] GSoC API mentoring help needed

Andy Allan gravitystorm at gmail.com
Mon Feb 20 08:19:38 UTC 2017


On 20 February 2017 at 01:04, Paul Norman <penorman at mac.com> wrote:

> 1. cgimap-ruby
>
> I don't yet have a student interested in this, but I'd like to see if one of
> the ones who has contacted me is. This could use a mentor who has dealt with
> ruby gems before, which I haven't. I have a feeling this part of the work
> isn't enough for a full project, so it could pull in something from a
> different API-related proposal.

I think this would be more than enough for a full project. I have
experience with the ruby side of things, but not the C++ side, so I
don't think I would be a good mentor. But the integration of
cgimap-ruby into the rails code would be very valuable, but perhaps
hard to get right. For example, while the basic integration would be
to get cgimap-ruby to create the document and let rails send that to
the client, the more advanced solution is to allow cgimap-ruby to
stream the response to the socket directly, without rails buffering
the whole thing.

> 2. website from API
>
> This is a project to change parts of the website to call the API instead of
> the database for object information. Good candidate pages would be the
> object browse ones (/node/<id>, etc). There are two different technical
> approaches to this, and depending on which route a student takes, the mentor
> might need different skills. The first of these is to do the processing of
> API results on the server and return HTML to the client, like
> http://osm.mapki.com/history/ does. The second is to do the processing of
> API results on the client with Javascript, like
> http://osmlab.github.io/osm-deep-history/ does. For the first, the student
> would be reproducing existing HTML output so the mentor would need knowledge
> of ruby and API calls. For the second, client-side javascript would be
> needed, but less ruby.

I can see the purpose of this, but I've never seen it as being as high
a priority as other developers do. 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 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!

Thanks,
Andy



More information about the dev mailing list