search

sul-dlss-deprecated / iiifManifestLayouts

Other
10 stars 5 forks source link

Adds functionality for a use of IIIF Auth access token, while also re… #99

Open mejackreed opened 8 years ago

mejackreed commented 8 years ago

…questing a resources info.json within manifestor.

Just a WIP using IIIF Auth

nein09 commented 8 years ago

This is great! When https://github.com/sul-dlss/iiifManifestLayouts/pull/94 is in, we may want to move this functionality into the CanvasObject.

iangilman commented 8 years ago

Now that #94 is merged, do we want to work on integrating this change?

/cc @aeschylus

nein09 commented 8 years ago

And where would we want to put it? To me, it looks like it should go in the CanvasObject, but I may be misunderstanding it.

aeschylus commented 8 years ago

It should be build in as a utility function or some type of special request proxy. It's purpose is to notify the client (in this case iiifmanifestlayouts, but potentially host software, like sul-embed or Mirador) that the image resource is protected or has degraded access.

Here is the IIIF Auth spec. No need to read it yet at this point, but the motivation section will set some context. There is a set of steps that the user may want to go through to authenticate themselves or gain access to the best version of an image available to them. We do want to make this data/process accessible through the API, but this is a low priority at the moment, as currently SUL-Embed is doing this itself (although in a less granular way.

The highest priority now is to get the example page with the clipping/fading/positioning/etc. of multiple tilesources working, then to make sure we're correctly delaying info.json requests and rendering that correctly. The last step should be to separate out the renderer/animation more so it is more intelligible, and so the core can communicate state to containing components more precisely through events.