As a result of this limited UI, write operations (such as creating a folder and writing to a file) require an application to ask for the estimated size, in bytes, they expect to use. The same practice is true for other offline storage APIs, like WebSQL DB, where one opens a database with a particular Temporary storage is easiest to obtain. In fact, you don’t even need to request it. By default, origins are given a modest amount of temporary storage, meaning they can use temporary storage without special permissions or the browser prompting the user to take some action.
Temporary storage is perfect for things like caching. In Google Chrome 13, the HTML5 Filesystem and the WebSQL DB share a pool of disk space that sites can collectively consume. A single site can consume up to 20% of the pool. As usage of the temporary pool approaches the limit for the pool as a whole (1 GB), least recently used data will be reclaimed.
Eventually, Application Cache and IndexedDB will also share in this temporary pool. Such a unified quota system also means there is no longer a 5 MB limit imposed on WebSQL DB. Persistent storage is just that, persistent. Data saved using this option is available on subsequent accesses to the same filesystem. Keep in mind, though, that even persistent data can be deleted manually by the user (either through a browser settings page or through direct filesystem operations on the OS).
So the data you save is never 100% guaranteed to be there. A key difference from temporary storage is that the browser asks the user for permission before allocating persistent storage space. In Chrome, this displays as an info bar To request new or additional storage space, call requestQuota() with the type of storage, size, and a success callback. As explained in the previous section, the browser prompts the user with a permission bar when PERSISTENT storage is requested. If the size passed to requestQuota() is less than the app’s current allocation, no prompt is shown. The current quota is kept.
If your app is requesting additional space (e.g., the new size is larger than the app’s existing quota), the user will be reprompted to accept that change. If the request is for TEMPORARY storage, again, no prompt will appear but other data may be evicted at the browsers discretion After the user grants permission to use persistent storage, your app is allocated the amount of quota it requested. There’s no need to ask for more quota until space becomes an issue. When that point comes, the best way to recover is to attempt the write operation, catch the QUOTA_EXCEEDED_ERR in the error callback, and request more persistent storage using requestQuota(). Don’t worry if none of that makes sense now. It will in the next chapter, Chapter 4, Working with Files.
Error callbacks are optional arguments to the API’s methods. However, it is always a good idea to catch errors for users, as there are a number of places where things can go wrong. For example, if you run out of quota, write access to the filesystem is denied, or a disk I/O operation fails. Error callbacks are passed FileError objects, which contain a code corresponding to the type of error that occurred. The code can be compared to the enum constants in FileError.
|If you need to buy the hard copy of this E-Book, Click here|
Download Using the HTML5 Filesystem API by Eric Bidelman easily in PDF format for free.