Serve JP2s without Oracle Java a.k.a; Use IIIF #243
Comments
|
I'm game. Especially if it means we get to integrate software from a community member. Anyone else have any thoughts? Kevin? |
|
So, there are some significant differences between my fork and the upstream (aside from upgrading JVM support, etc.) Perhaps the most prohibitive (for this purpose) is that it's not intended to be distributed as a war file that runs in Tomcat, like adore-djatoka. It's packaged with Jetty (with the intention you'd run the servlet container on it's own "image server" VM). You could run it on the same machine but then you'd have two servlet containers running there (even though Jetty is lighter weight, that's less than ideal). It's meant to be much easier to run (no configuring kakadu library locations, etc.) but that binds it to Jetty (with the way that I've done it). There is IIIF v1 support and currently a permanent Pairtree cache for things delivered via that route. I have a desire to look at what would be involved with upgrading Islandora to the IIIF version of OpenSeadragon but haven't had much time lately. I also have a ticket (to myself) to have methods for cleaning the cache (of things that don't match a pattern -- things that aren't OSD tiles, for instance... though age could be a pattern too). The above paragraph isn't necessarily important to Islandora, since things requested from the OpenURL interface don't go in that cache. But, the result of that different direction is that I don't expose a lot of control of the underlying adore-djatoka cache settings in my config (as I was wanting to move away from that and rely on the permanent cache). That's a difference that might pose a problem for an Islandora implementation. There are tile pre-generating scripts for sites that would rather not generate them dynamically, but they work with the latest stable version of OpenSeadragon and I'm not sure would work with the version that Islandora uses. There is an argument there whether people would want to pre-cache and keep a permanent cache around, which is the direction I was heading (I can understand use cases for both sides). Anyway, we are interested in doing some work with IIIF so I expect to being able to put some hours towards the project again soon (at the very least upgrading to IIIF v2) but maybe it would be worth carving out a list of things that better integration would require. That said, I don't see making it work with Tomcat as being a high priority for us so I'm not sure about an official integration -- something to discuss, I guess. |
|
For my part, I wouldn't be that concerned about running a separate container; not using Tomcat means it'd be less painful to configure than current Djatoka (inasmuch as it wouldn't impact your Fedora environment), and as a bonus there would be better threading than we have currently :) |
|
I'll second that. I have no problems with it running standalone. In fact, making stuff like this run on other machines in a distributed environment is one of main goals of this project. As to upgrading OpenSeaDragon, all of the viewers are going to have to get re-written as custom Drupal field renderers, so we'll probably want to take the time to evaluate upgrading all of them anyway. I think now's a good time to consider upgrading as much as possible. A lot of what we're working with is quickly becoming out of date if not unsupported altogether. |
ruebot
changed the title
|
Dropping some links in: |
|
Closing old use cases until after MVP doc is released. |
Tuesday Feb 03, 2015 at 14:18 GMT
Originally opened as https://github.com/islandora-interest-groups/Islandora-Fedora4-Interest-Group/issues/12
Reformatting this to use the Use Case template.
Remarks:
The text was updated successfully, but these errors were encountered: