Asking about use cases that can be served by a filesystem API, but not
by IDB, is reasonable [and I'll respond to it below], but it misses a
lot of the point. The users I've talked to like the FS API because
it's a simple interface that everyone already understands, that's
powerful enough to handle a huge variety of use cases.
Sure, the async API makes it a bit more complicated. Every API that
handles large data is stuck with the same overhead there. But
underneath that, people know what to expect from it and can figure it
out very quickly.
You just need to store 100KB?
1) Request a filesystem.
2) Open a file.
3) Write your data.
Need a URL for that? Sure, it's just a file, so obviously that works.
Want it organized in directories just like your server or dev environment?
Go ahead.
You don't have to write SQL queries, learn how to organize data into
noSQL tables, or deal with version change transactions.
If you want to see what's in your data store, you don't need to write
a viewer to dump your tables; you just go to the URL of any directory
in your store and browse around. Our URLs have a natural structure
that matches the directory tree. If you add URLs to IDB, with its
free-form key/value arrangement, I don't forsee an immediate natural
mapping that doesn't involve lots of escaping, ugly URLs, and/or
limitations.
On to the use cases:
Things that work well in a sandboxed filesystem that don't work well
in IDB [or any of the other current storage APIs] are those that
involve nontransactional modifications of large blobs of data. For
example, video/photo/audio editing, which involve data that's too big
to store lots of extra copies of for rollback of failed transactions,
and which you don't necessarily want to try to fit into memory.
Overwriting just the ID3 tag of an MP3, or just the comment section of
the EXIF in a JPEG, would be much more efficient via a filesystem
interface. Larger series of modifications to those files, which you
don't want to hold in memory, would be similar.
I know Jonas wants to bolt nontransactional data onto the side of IDB
via FileHandle, but I think that the cure there is far worse than the
disease, and I don't think anyone at Google likes that proposal. I
haven't polled everyone, but that's the impression I get.
Beyond individual use cases:
When looking at use cases for a filesystem API, people often want to
separate the sandboxed cases and the non-sandboxed cases ["My Photos",
etc.]. It's also worthwhile to look at the added value of having a
single API that works for both cases. You have a photo organizer that
works in the sandbox with downloaded files? If your browser supports
external filesystems, you can adapt your code to run in either place
with a very small change [mainly dealing with paths that aren't legal
on the local system]. If you're using IDB in the sandbox, and have a
different API to expose media directories, you've got to start over,
and then you have to maintain both systems.
One added API?
It's pretty clear that people see the value of an API that lets one
access "My Photos" from the web. That API is necessarily going to
cope with files and directories on some platforms, even if others
don't expose directories as such. If we're going to need to add a
filesystem API of some kind to deal with that, also using the same API
to manage a sandboxed storage area seems like a very small addition to
the web platform, unlike the other storage APIs we've added in the
past.
Regarding your final note: I'm not sure what you're talking about
with BlobBuilder; is that the EXIF overwrite case you're trying to
handle? If so, File[Handle|Writer] with BlobBuilder and seek seems to
handle it better than anything else.
Eric
On Tue, Sep 25, 2012 at 11:57 AM, Maciej Stachowiak wrote:
>
> On Sep 25, 2012, at 10:20 AM, James Graham 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 m