Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there interest in extracting parts of mapwarper / nypl-warper into a Gem? #63

Open
mejackreed opened this issue May 24, 2016 · 6 comments

Comments

@mejackreed
Copy link

Hi,

nypl-warper and mapwarper are great projects. Is there interest to extract out some of this common functionality into a gem (rails engine)? This would allow others to more easily customize their own instances of mapwarper and provide a path for updates and semantic versioning.

@mgiraldo
Copy link
Contributor

mgiraldo commented Jun 1, 2016

That would be great. This project is an assembly of many separate parts so it is a complicated procedure. What parts are you imagining on having gem-ified first?

@mejackreed
Copy link
Author

Though my knowledge of mapwarper internals is limited, I think there are some wins for popping the georeferencing code out.

Potentially:

 - app
         / assets
         / controllers
         / models
         / views
  - config (for needed config only)
  - vendor

lib is unclear to what extent that is entangled. But some of this looks like it could come over or be popped out to another gem.. or use simple_enum ?

As I mentioned I'm not extensively familiar with the internals here and how intertwined they are. But willing to help out on pulling this apart (and explore what it would take).

Ideally I think the goals for me would be:

  • separation of "mapwarper" functionality from implementation details
    • login service(s)
    • capistrano and deployment details
    • harvesting tasks or ingestion
    • remove the need for the /warper prefix
  • allow for a range of dependencies (removes the Gemfile.lock)
  • enable adopters to create new custom importers

@mgiraldo
Copy link
Contributor

mgiraldo commented Jun 2, 2016

remove the need for the /warper prefix

would be high in my list... it's a confusing remnant of NYPL-centric code

enable adopters to create new custom importers

makes it very useful for third-parties (and would better decouple it from NYPL API)

to this date I've made a total of zero gems so it is unclear to me the process to do this. I suppose you start by decoupling as much code as you can.

eg for login services: move omniauth stuff to it's own config, add some config params that state which, if any, login services to use

open to any ideas as to how to go about this

@timwaters
Copy link
Contributor

Good ideas, I have thought about making it more modular before, and even making some of the common functions into gems/libraries.

For the libraries, I think the primary ones would be one for warping and RMS calculations and one for cropping and one for WMS / Tiles responses.

For a rails engine - I think making it more modular would be great. The main points is the integration with any repository / upload, and any export and caching solutions.

You may be interested in work I'm currently doing on the wikimaps warper project which would be to re-write the API to make it so that a 3rd party javascript application could be written. The aim is to separate the backend and frontend entirely, so we can imagine that the warper, in the future, would be just a set of APIs and much more modular in nature.

@mejackreed
Copy link
Author

It would be good to understand the dependency on mapserver here as well. Trying to work with this locally on OSX I still haven't been able to build mapserver and run the application. Looks like I'm going to have to punt to Ubunutu.

I do have some experience with extracting an application out to a gem and may play around with that once I get my env setup.

@mapninja
Copy link

mapninja commented Jul 6, 2016

Just putting in a +1 on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants