HTML5 offline storage. File storage? Directories a

Question

For storing data offline WebApp can use:

• session storage, "advanced version of cookies"
• key/value based Web Storage (AKA local/global/offline/DOM storage)
• sql-based Web SQL Database (deprecated) and Indexed Database API
• FileReader and FileWriter API (requires user to select files each time the application loads)

But apparently there is no File Storage. Of course, there is a manifest-based caching, but it's just a cache and is not supposed to be used as a user data storage.

Does it mean that the user of WebApp is forced to use some sort of a cloud file storage?

Is there any way to save large files on user's local machine? Or maybe some way to select a local folder web application can use to store user data?

Edit. Security. HTML5 already has the ability to write big portions of data to user's local machine. I don't see any security issues if a browser will provide another, file-based abstraction to store data. It can be some virtual machine, virtual filesystem, whatever.

Hm, I think, it is possible to write JS filesystem and store it as a blob in SQL...

Similar questions.

Update: Hm... recently I've found this and this. Maybe it is what I'm looking for... Yes, it is! See the answer below.

Answer 1

As mentioned by others here, the FileWriter and FileSystem APIs can be used to store files on a client's machine from the context of a browser tab/window.

However, there are several things pertaining to these APIs which you should be aware of:

• Implementations of the APIs currently exist only in Chromium-based browsers (Chrome & Opera)
• Both of the APIs were taken off of the W3C standards track on April 24, 2014, and as of now are proprietary
• Removal of the (now proprietary) APIs from implementing browsers in the future is a possibility
• A sandbox (a location on disk outside of which files can produce no effect) is used to store the files created with the APIs
• A virtual file system (a directory structure which does not necessarily exist on disk in the same form that it does when accessed from within the browser) is used represent the files created with the APIs

IsolatedStorage, which hasn't been mentioned as of yet, also allows for file i/o from a tab/window context, but it is made available through solely through Silverlight and requires the use of managed code to access. It, like FileSystem, also exists in a sandbox and makes use of a virtual file system.

Given the high market penetration of both Chromium-based browsers and Silverlight (support for which, interestingly enough has been dropped by such browsers), you may find a solution which uses the first of the above approaches available on a client machine satisfactory.

BakedGoods, a Javascript library that establishes a uniform interface that can be used to conduct common storage operations in all native (including FileSystem), and some non-native (including IsolatedStorage) storage facilities, is an example of such a solution:

//Write file to first of either FileSystem or IsolatedStorage
bakedGoods.set({
    data: [{key: "testFile", value: "Hello world!", dataFormat: "text/plain"}],
    storageTypes: ["fileSystem", "silverlight"],
    options: {fileSystem:{storageType: Window.PERSISTENT}},
    complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});

Just for the sake of complete transparency, BakedGoods is maintained by this guy right here :) .

Answer 2

There is a way to save relatively large files to a users hard drive if you are willing to use Flash. Look into Downloadify:

http://www.bitrepository.com/downloadify-client-side-file-generation.html

Downloadify allows you to send data to a SWF and have that SWF create a file on the users machine. My recommendation would be to store the data via one of the methods you listed, Webstorage, sqlite database, etc. Put all your assets, including the SWF in the manifest file so everything is cached locally to the browser. You can then pull information from your db or webstorage and use the SWF to create the files you need.

I'm not sure if you will be able to read these files back into your web application.

Another option to save data is by using link tags with the data URI scheme. However, I'm not sure if it is supported in all the major browsers at the moment.

Answer 3

For security reasons you can't write files to a user's local filesystem in case it gets used for nefarious purposes by evil people.

That's not likely to change, and that's a good thing.

Answer 4

http://fsojs.com wraps the FileSystem API effectively, if you want an easy solution

Answer 5

Why not use localStorage while the user is editing a document and the FileWriter API when they want to save it to disk? Most people are used to seeing a save dialog pop up when saving a document.

The only scenario I can think of that warrants userless access to the FileWriter API is an autosave feature, but autosaving to localStorage can be just as good.

Answer 6

At last, I've found it! Here's the answer:

I’ll have the DOMFileSystem with a side of read/write access please wrote:

Eric Uhrhane of Google has been working on the working draft of the File API: Directories and System specification which defines a set of APIs to create a sandboxed filesystem where a web app can read and write data to.

Wow! I'm so excited!