This solution still isn't technically correct because it could take more
than 40 seconds to download a file. I could simply not revoke any files,
but then users would run into issues once they have saved a cumulative
total of over 500MB (
https://bugs.chromium.org/p/chromium/issues/detail?id=375297 )
Complain to @sicking and @arunranga for creating and standardizing an
incomplete revocation API.
[This comment](https://github.com/eligrey/FileSaver.js/issues/104#issuecomment-64328197) indicates a willingness to include a link to a bower-compatible fork of FileSaver.js. I created the fork so that I could install it using bower (via rails-assets.org) and wanted to share.
Based on [previous statements](https://github.com/eligrey/FileSaver.js/pull/109#issuecomment-65692833) about converting the package to semver, I've used a versioning system that reflects this package actual version. The version I uploaded is 1.20150304.1. Going forward I plan to change the minor version when new versions are released, with the date they are released as the minor version.
For example, if a new version were released today, I would update the bower package to version `1.20150322.0`.
I know that you [tweeted](https://twitter.com/sephr/status/542978804441169920) a recommendation to use the patch version as the date, but since most package managers treat patch bumps as easy upgrade paths, the minor version seemed more appropriate.
I raised the arbitrary-ish revocation timeout from 10ms to 500ms. I hope
to refine this value in the future with input from YOU, my users reading
this.
Please comment on this commit with any feedback you have.
@stesch13's concerns can be found at
https://github.com/eligrey/FileSaver.js/commit/485930a#commitcomment-8768047
Eli Grey