persistent visualization rendering as a sub-page

[keighrim]

When user posts a MMIF, the app renders HTML and returns it directly to the browser session. Instead, we'd like to the app to generate sub-pages for each post with randomized page identifier to store temporary files (vtt, thumbnails, etc.) as well as to keep the rendering output semi-permanently.

[haydenmccormick]

Re clamsproject/clams-python#93, how could this affect our current concept of a mmif "consumer"? This version of the visualizer isn't quite collection-level, but it's not really input->output either, since it has some limited memory of earlier outputs.

[keighrim]

I think the original design still stands, as this will turn one input MMIF into a directory where there's the primary HTML file and its content files (vtt, iiif, etc.) We can think of the directory itself, or the new URL assigned to that directory as the result of the consumption.

[keighrim]

I was testing the working branch, and found that because of the way it's implemented to perform "lazy" loading of OCR visualization (that relies on a browser session), the generated sub-page won't be re-accessible once the session is lost. @haydenmccormick correct me if I'm wrong.

[keighrim]

Another feature we discussed in last group meeting was to use sha1 hash value (40-character long) generated from the full content of the input MMIF as the subpage URL suffix. Because files with identical contents are almost guaranteed to return the same sha1 hash values, this implementation will effectively work as a caching mechanism for re-upload of the same file over and over.

[keighrim]

28 implements SHA1 based visualization id generation and decoupling from the browser session. I'm not sure if there'll be any side effect of departing from usage of session, though.