Sandboxed Filesystem use cases? (was Re: Moving File API: Directories and System API to Note track?)

On Sep 25, 2012, at 10:20 AM, James Graham <jgraham@opera.com> wrote:

> 
> In addition, this would be the fourth storage API that we have tried to introduce to the platform in 5 years (localStorage, WebSQL, IndexedDB being the other three), and the fifth in total. Of the four APIs excluding this one, one has failed over interoperability concerns (WebSQL), one has significant performance issues and is discouraged from production use (localStorage) and one suffers from a significant problems due to its legacy design (cookies). The remaining API (IndexedDB) has not yet achieved widespread use. It seems to me that we don't have a great track record in this area, and rushing to add yet another API probably isn't wise. I would rather see JS-level implementations of a filesystem-like API on top of IndexedDB in order to work out the kinks without creating a legacy that has to be maintained for back-compat than native implementations at this time.

I share your concerns about adding yet-another-storage API. (Although I believe there are major websites that have adopted or are in the process of adopting IndexedDB). I like my version better than the Google one, too, but I also worry about whether we should be adding another storage API at all.

I think we need to go back to the use case for sandboxed filesystem storage and understand which use cases cannot be served with IndexedDB.


Here are some use cases I have heard:

(1) A webapp (possibly working on offline mode) wants to stage files for later upload (e.g. via XHR).
    Requirements:
        - Must be able to store distinct named items containing arbitrary binary data.
        - Must be able to read the data back for later upload.
        - Must be able to delete items.

(2) A web-based mail client wants to download the user's attachments locally, then reference them by URL from the email and allow them to be extracted into the user's filesystem space.
    Requirements:
        - Must be able to store distinct named items containing arbitrary binary data.
        - Must be able to reference items by persistent  URL from constructs in a webpage that use URLs.
        - Must be able to delete items.

(3) A web-based web developer tool downloads copies of all the resources of a webpage, lets the user edit the webpage live potentially adding new resources, and then uploads it all again to one or more servers.
    Requirements: 
        - Must be able to store distinct named items containing arbitrary binary data.
        - Must be able to replace items.
        - Must be able to reference items by persistent  URL from constructs in a webpage that use URLs.
        - Must be able to delete items.
        - Must be able to enumerate items.
    Highly desirable:
        - Hierarchical namespace.

(4) A game wants to download game resources locally for efficient operation, and later update them
    Requirements: 
        - Must be able to store distinct named items containing arbitrary binary data.
        - Must be able to replace items.
        - Must be able to reference items by persistent URL from constructs in a webpage that use URLs.
        - Must be able to delete items.
    Highly desirable:
        - Hierarchical namespace.


I believe the only requirement here that is not met by IndexedDB is:
    - The ability to reference an item by persistent URL.

IndexedDB has enumeration, hierarchical namespace, ability to add, replace, remove, get, etc.


Are there other use cases? In particular, are there use cases that justify a whole new storage API instead of adding this one feature to IndexedDB?


Note: one aspect of the MinimalFileSystem proposal that is not obviously required by any of these use cases is the ability to incrementally update a file (beyond what you could already do with slice() and BlobBuilder). Basically the whole FileHandle interface. Is there truly a use case that you can't satisfy by using BlobBuilder to make your update and then atomically replacing?


Regards,
Maciej

Received on Tuesday, 25 September 2012 18:59:53 UTC