W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

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

From: Charles Pritchard <chuck@visc.us>
Date: Thu, 03 Feb 2011 22:07:09 -0800
Message-ID: <4D4B978D.9070508@visc.us>
To: ifette@google.com
CC: Shawn Wilsher <sdwilsh@mozilla.com>, João Eiras <joao.eiras@gmail.com>, public-webapps@w3.org
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT