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

On 2/3/2011 10:36 PM, Ian Fette (イアンフェッティ) wrote:
> On Thu, Feb 3, 2011 at 10:07 PM, Charles Pritchard <chuck@visc.us 
> <mailto:chuck@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.