FYI, it's RAIS, not RAILS :)
One problem you'll face is that chronam doesn't have a way to configure image server URLs. We found that we had to modify quite a few things to make chronam work with an external image server. And even then, we didn't make it IIIF, because initially we only wanted something that could work with chronam.
The changes we made can be seen at https://github.com/uoregon-libraries/oregonnews/commit/c8aad3287bf80cc4ca6716b91abd8b714be956a1, but there are some caveats:
- The changes to our sub-app (everything under oregon/) obviously would have to be dissected and figured out manually, which may be a LOT of work
- The changes to core may not work for you, as our version of chronam was old AND already customized by us
- If you make this many changes to core code, pulling down any chronam updates will potentially become infeasible
It's probably possible to build some kind of Apache proxy magic to intercept all dynamic image requests and forward them to a tile server, and that would probably be less risky, but it might be a lot of work to figure out every URL pattern you need to intercept, and translate them to something IIIF-compatible.
From: Data, API, website, and code of the Chronicling America website <[log in to unmask]> on behalf of Mary K Willoughby <[log in to unmask]>
Sent: Monday, March 6, 2017 7:51 AM
To: [log in to unmask]
Subject: Using ChronAm with alternate IIIF compliant image server
Other than Oregon's RAILS server, is anybody out there in ChronAm land using a different IIIF image server? We're determining what our production setup is going to look like and are wondering about the cost/benefit of replacing the included server with a different one in the hope of getting faster rendering and possibly more flexibility in how we deploy everything. Any success stories, horror stories, reflections, cautionary tales, etc. would be greatly appreciated.
Thanks very much,
Digital Library Analyst
Digital Library of Georgia