On 2/3/2011 9:39 PM, Ian Fette (イアンフェッティ) wrote:
I'm not sure FileSystem is necessarily any trickier from a user's
perspective -- it's all storage that is taking up space on my HD (at
least, for now the filesystem is just a directory under the user's
profile in Chrome). I think it fits fine in the unified quota model.
(And FWIW we are looking at replacing the SQLite backend for Indexed
DB in Chrome, so it's not generally safe to make such assumptions
about how implementations currently work remaining the same as you
have below ;-) Still though, as an end user or developer using the
API, I really shouldn't have to care about such details.)
Thanks for sharing. I'm sure you'll see good results replacing the backend.
indexedDB can be more efficient than FileSystem.
FileSystem is an API to the OS service, idb is not.
There are no issues with idb keynames, innodes are not an issue:
idb can be optimized for target platforms, which is good when
the underlying file system is a bad match for the file sizes / dir
lengths / file names.
FileSystem is useful when you want OS-recognized files.
It's great for moving files in and out of the browser sandbox; OS
indexing services, and so on.
That's been my experience:
We're using file system, as we do want individual files to be show up to
the OS,
but for generated content, especially thumbnails of images, that data
would be better
stored in idb. Lots of small files which would be better stashed in a
data store.
-Charles
