Dynamic cache manifest generation;

[jqnatividad]

added dynamic cache manifest generation to allow MigaDV apps to work offline for all referred media assets as well, not just the CSV data; Added Viewer.js images to manifest as well

[yaronkoren]

That's quite clever! I don't know if I would have thought of having the browser's data refresh re-create the cache.manifest file itself. However, there may be some problems with this setup:

• It's potentially a massive amount of file writes.
• If there's more than one app with audio/video files, I'm not sure that this will work - if the user switches from one app to another without refreshing the data for either one, will the browser's conception of the cache.manifest file correctly handle the files for both? For that matter, I'm not sure it'll work even if the user does refresh the data - the application cache stuff (i.e., cache.manifest) doesn't seem to always refresh itself even when it should.
• on that note, what if one user refreshes the data for app A, and then another user refreshes the data for app B, and then the first user's browser reads the manifest.cache file? Won't it hold the wrong contents?

It could be that I'm misunderstanding how the current code works, though, or that I'm too nervous about the whole thing. What do you think?

One other possibility is to have that script be called manually, by the administrator - and have it store in cache.manifest the set of files for every app. It's not nearly as nice a solution, but it could work better.

[jqnatividad]

Good points. I guess I was too focused on the specific reqts of the project I was working on and didn't anticipate the massive rewrite problem. To that end, what if I implement these changes in response to the points you raised:

• have a "Dynamic manifest" flag in settings.ini that is off by default. The admin can turn on the flag to generate the manifest and turn it off once its created. Or for the local webserver usecase I was working on, just leave it true all the time.
• the cache.manifest file is a global one. In my testing, switching between apps wasn't a problem, even with the thousands of records. Was pleasantly surprised how the browser was asynchronously prefetching the resources too. I'm also adding some code to force the cache to be updated once the refresh is done.
• that is a valid concern. For centrally-maintained apps, turning off dynamic manifest should solve the issue. Maybe I can implement some logic to check if the local copy is out-of-sync to alert the user? Its a good way to let users know that there is an update as well.

I originally was implementing a cache.manifest for every app, but found out that there is one application cache per URL, and since all apps on the same server share the same URL, it will have to be in one cache.manifest file.

[yaronkoren]

Well, here's the big question I have: will this code work if there are multiple apps that have media files to be cached? That's the part I'm most worried about. Are you saying it's not a problem?

Also, you mentioned the local webserver - is the caching behavior different if it's "localhost"?

[jqnatividad]

Yep. Its not a problem. I copied the example apps on migadv.com and found that they all worked with one global manifest file. The gotchas were the Parks example which had some invalid image URLs, and the WM2013 example which had some huge video files. Both caused appcache creation to fail. And since appcache is all or nothing, that meant there was no caching for all the apps. But as soon as I removed the invalid URLs and put smaller videos, the cache was created as expected.

And no, the behavior is the same for localhost. What I was referring to is the project I'm working on where the webserver was running locally on a USB stick. Even if the USB stick is removed and the local webserver is down, MigaDV apps were still fully functional.

BTW, I'm amending this pull request with some more tweaks as I proposed above.

[yaronkoren]

Now that there's the compiler step, the dynamic cache.manifest modification should be done directly there, in the PHP - thus I have to close this patch, but hopefully we can use this code in part.