About my version of ruby-libosrm and debate about merging

[mhaulo]

Hi there!

I found this gem some time ago when I was searching ruby bindings for libosrm. Since it wasn't finished, I couldn't use it in my application.

Recently I managed to put aside some time and decided to contribute some missing stuff. Unfortunately not everything worked out of the box. Also, it is worth noting that I was learning how to build Ruby gems and how to use Rice library on the fly.

Due to my time constraints and the need to get a working gem I had to do things the I was more familiar with. Long story short, my version ended up being basically a major rewrite of ruby-libosrm. You can find it here: https://github.com/mhaulo/ruby-libosrm

I'm not sure how to proceed with a change this big. Some features are still missing. Some things need a lot of tidying up. Also, a pull request this big feels kind of...I don't know – harsh?

Anyway, the code is there. Have a look. Let me know what you think.

[Smarre]

Hi,

interesting work there. As you can see, I haven’t really put effort to this project, as the need I had for it has subsided.

I need to have closer look at the code, but I think the most important question is that who has time to do some basic maintenance to ensure that new versions will continue to work? At least with my approach, this project mapped upstream API pretty closely, so it actually even broke once while I was doing development. I can just transfer this project to you if you happen to have interest in maintaining this. Otherwise I’ll try to skim through the code soon and merge it.

[mhaulo]

I have an active application thah uses route, match, and nearest services at the moment. For now, I don't know about other OSRM services - table, trip, and tile. So basically I can do some level of maintenance, but cannot guarantee fast matching with OSRM backend changes. More contributors would be nice, and I'm hoping there will be more interest if this library matures a little bit more so that it'll be easier to do small tasks.

[mhaulo]

Here's summary of the changes I made:

The monolith

The bulk of code is now in one big class, OsrmWrap. The Rice entry points are now direct calls to public methods in OsrmWrap. This was partly done because it was easier for me to follow and study the code when it was in one place.

Cucumber -> Minitest

I couldn't get original tests to run. I also had some existing tests written with Minitest, and I was mostly able to simply copy them here.

The need for better parsing code

The monolith class is big, but not enormous – less than 1000 lines. A lot of it consists of code which parses the responses from the OSRM backend. And everything is done manually. However, OSRM uses Mapbox Variant class which allows using an "apply_visitor" function. I did not have enough time to study how that works, but I figured it makes the parsing part a lot shorter. Therefore, if parsing responses was done with that, the monolith would end up being actually quite small class.

[Smarre]

Sorry for delay, but I got around to read through the code.

My approach was more of trying to provide features of libosrm to Ruby side, rather than give few simple functions that are also available over HTTP API. My specific use case was doing a zillion specific queries, where most overhead would’ve been doing a single request for each of the queries, hence I focused on implementing features suited to my use case. What is the actual problem your way fixes over mine (outside of actually makes the code work with most up to date libosrm)?

[mhaulo]

Need for certain features as well as personal coding style preference, I guess. But the driving factor indeed was to get a functional gem meeting my requirements, in a very limited time.