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

On Thu, Feb 3, 2011 at 10:07 PM, Charles Pritchard <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.


>
>
> -Charles
>
>