Closed mudcube closed 10 years ago
chrome.syncFileSystem.requestFileSystem
is a chrome apps API. I'm not sure why we'd support it.
Chrome has no plans to deprecate the FS API. Not sure on the quota api
Good point, for idb.filesystem it wouldn't make sense as it's intended as a polyfill for the proposed W3C requestFileSystem specs.
I do think it would would be cool to have in filer.js. Or perhaps another module. I've been considering making a syncFileSystem shim that works in the browser (outside of chrome packaged apps) w/ an authenticated Google Drive account—as its' a really neat feature. Or it could even use a generic remote server, setup with your favorite server side language, using the same api. I just love to be able to write once and deploy everywhere.
Should chrome.syncFileSystem.requestFileSystem be supported?
syncFileSystem has a "getUsageAndQuota", which is slightly different than persistentStorage.requestQuota, but similar results (returns object vs vars). I'm not sure whether that would fit more into filer.js (df) or here, but seems important as well.
On that note, do you happen to know whether navigator.*.requestQuota is going to be depreciated entirely? I'm noticing in the console it's referred to as DepreciatedStorageQuota. I could see that function moving on top of requestFileSystem.requestQuota like the chrome.syncFileSystem version currently works... although tricky as there is PERSISTENT and TEMPORARY versions.
I'm hoping Chrome is standing behind requestFileSystem in the future, even though it's not being standardized (although with your shim it wont matter too much). Any inside information on that?