On 20 February 2017 at 01:04, Paul Norman <penor...@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 _______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
