Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)

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

Received on Friday, 4 February 2011 06:07:40 UTC