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.Received on Friday, 4 February 2011 07:22:10 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:16 UTC