On 2/3/2011 10:36 PM, Ian Fette (イアンフェッティ) wrote:
On Thu, Feb 3, 2011 at 10:07 PM, Charles Pritchard <ch...@visc.us
<mailto:ch...@visc.us>> wrote:
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.
I'd rather not de-rail the thread, that said I am surprised you see
this behaviour. It should be the exact opposite - we should be able to
deliver much better performance from the filesystem api for binary
data. Test cases where that's not the case are always welcome.
I was referring to directory listing and disk usage. small files can
waste a lot of space on older file systems.
I mean to talk about the FileEntry -based APIs.
I'm not seeing behavior where idb is beating the filesystem api; I'd
prefer to use idb, but the
sqlite implementation does not have an optimized large object store.
