Re: [OSM-dev] GSoC API mentoring help needed

[Paul Norman]

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.




___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] GSoC API mentoring help needed

[Andy Allan]

On 20 February 2017 at 01:04, Paul Norman  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/, 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

[OSM-dev] GSoC API mentoring help needed

[Paul Norman]

Much to my surprise, I have 2-4 students issued in my API-related GSoC 
proposals. This is more than one person or even two people can mentor, 
so I'm asking for help. The cgimap-ruby, cgimap read-only support, 
cgimap write support, and make the website use the API


Some of the proposals involve cgimap, and I'm probably the best suited 
to mentor those because I'm one of the three significant cgimap 
contributors. Instead, there's two proposals well suited to someone else.


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.


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/, 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.


If you're interested and available to help mentor, please contact me 
off-list.




___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev