Closed glenrobson closed 1 year ago
@digitaldogsbody I was having a look a the v2 manifest and although we don't directly link to cantaloupe the manifest points to the local server iiiify server e.g:
"service": {
"@context": http://iiif.io/api/image/2/context.json,
"@id": "https://archivelabs-iiif-archivelab-org-presentation-v3.ux-fnf-misc.archive.org/iiif/mms_metcalf_box_002$0",
"profile": https://iiif.io/api/image/2/profiles/level2.json
}
Which calls your code that redirects to cantaloupe so I don't thing there is anything to do here.
Ok good stuff! We can revisit in the future to update the v2 code to get the cantaloupe address directly rather than having to make the client make an additional request just to get the redirect
Unless of course we want to obscure the canteloupe address in the manifests and serve a redirect also for v3, which would allow the address of the canteloupe deployment to move while keeping the service
URI in the manifests static (and with a nice iiif.archive.org URL as well). I vaguely recall discussing this but I don't remember what we decided in the end.
I think it's nice to leave the iiif.archive.labs url there for now and update it if we move to iiif.archive.org/iiif/image.
Agreed.
Presumably when the production service goes live with the DNS, the current Canteloupe instance (or whatever production version replaces it) will be reverse-proxied behind iiif.archive.org/iiif/image as well, so we should make a reminder to update the URL served in v3 manifests away from the current https://services-ia-iiif-cantaloupe-experiment.dev.archive.org/iiif/ that is returned.
Make v2 use cantaloupe.