Alternate Image API services

[Robert Sanderson]

All,

An issue was raised by Petr Pridal at Ghent around allowing alternate endpoints for content served by the Image API.  The background for the issue is that browsers have limits on the number of connections they can open to a single system at once, and thus if a single image server is providing hundreds of thumbnails or hundreds of small tiles, the user experience will be degraded as those requests are queued up even if the server could handle them.

The typical solution for this is to have a content distribution network, where many servers can deliver the same content, and it makes no difference which of them you get it from.  In order to do that even on a small scale, you need to know the URIs to request, and thus the need for alternates in the info.json response.

Great... sounds easy, right?

Except that it's no longer the case in HTTP2, and HTTP2 is already supported by Edge, Chrome, Firefox, Safari and Opera.  http://caniuse.com/#feat=http2

Another use case suggested was to have pointers to other institutions that have the same content, but the behavior for clients would be different in this case.  The CDN use case the client should evenly distribute its requests. The other institution with the same image is more of a backup plan, and the client should still use the primary institution.

The question for the list is ... should we add alternates for the CDN case to info.json, given that it is unnecessary in HTTP2 which is widely supported? In discussions amongst the editors we felt that we would prefer to encourage adoption of HTTP2 (with encryption, so https/2) rather than work around it in the spec, but that's not going to be a short term solution for many institutions.

So ... is this something that the community should prioritize and adopt, or can we wait it out a little longer and see if the web solves it for us?

Many thanks!

Rob

--

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305

[Another Peter Account]

Hello Rob, and all

This is very close to the question I just asked, about some sort of shared load/redirects among IIIF servers, to permit requests to be sent to a pool of servers all sharing IIIF data, so that if one server is down another can take up the request. The late disasters at the British Library dramatize the need for something like this.

Any thoughts?

Peter Robinson

University of Saskatchewan/University of Venice Ca' Foscari.