https://stackoverflow.com/questions/20555402
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianAs you noted, the File-system API and IndexDB are not widely supported. That said, I think the solution is dependend mostly on your target audience.
Browser Support
IndexedDB is supported by more browsers than the File-System API. and as this article on Firefox's opinion of the File-System API points out, you can perform the same operations of storing files in IndexDB that you'd be able to perform on the File-System API. There are even javascript libraries that implement the File-System API over IndexedDB.
File sizes/Disk Space
With both technologies, you'll have to manage requesting quotas when limits are exceeded.
a quote from IndexedDB Storage Limits via developer.mozilla
There isn't any limit on a single database item's size. However there may be a limit on each IndexedDB database's size. This limit (and the way the user interface will assert it) may vary from one browser to another.
I do not know what the maximum amount of storage is for IndexedDB on all the browsers, it sounds like Firefox itself posts a request confirmation to the user for permission to store more than 50MB - so you can use what's available to the browser. IE10 has Approximately a 250MB limit see here for more on IE10. I Read some posts on a 5MB Quota on Chrome, but I think it follows the rules of Temporary Storage.
With the File-System API you have unlimited available space for the File-System, if you use Persistent Storage(but here you have to make a quota request from the start, so it's similar to the way Firefox does the Quota request). Temporary Storage has an actual limitation depending on the harddrive space available and some other things(Read this for more info on limitations of the File-System Quota)
I can't speak from experience for IndexedDB on very large files.images, but as for the File-System API, it does a marvelous job performance wise with read and write operations for GB worth of files. You can have single BLOB's hundreds of MB in size and partition various segments. That said, it doesn't sound like that is necessary for your game, since your file sizes (individual file sizes that is) are probably not going to exceed double digit MB.
Conclussion
IndexedDB is probably your best option, considering you're making a web-game and to reach more people, you need to use the API's that are usuable by most people.
The following code snippet is from an article specifically on downloading, writing and reading image files from IndexedDB. After reading the article, the idea of URL rewriting doesn't seem all that daunting compared to what it'd be in the File-System API.
// Retrieve the file that was just stored
transaction.objectStore("elephants").get("image").onsuccess = function (event) {
var imgFile = event.target.result;
console.log("Got elephant!" + imgFile);
// Get window.URL object
var URL = window.URL || window.webkitURL;
// Create and revoke ObjectURL
var imgURL = URL.createObjectURL(imgFile);
// Set img src to ObjectURL
var imgElephant = document.getElementById("elephant");
imgElephant.setAttribute("src", imgURL);
// Revoking ObjectURL
URL.revokeObjectURL(imgURL);
};
