On Thu, Feb 3, 2011 at 9:23 AM, João Eiras <joao.ei...@gmail.com> wrote: >>> Should probably be QuotaInfo or even QuotaManager ? Storage can and >>> will be confused with Web Storage. >>> >>>> // storage type >>>> const unsigned short TEMPORARY = 0; >>>> const unsigned short PERSISTENT = 1; >>>> >>> >>> Only two values seem not enough for me and I disagre with the >>> nomenclature. Would be betteer to have >>> LOCAL_STORAGE, SESSION_STORAGE, WEB_SQL_DBS, INDEXED_DB and so on. But >>> that would create artificial dependencies with the other specs, so it >>> would be better if "type" passed to the query and request functions to >>> just be an opaque string which would allow any offline storage spec to >>> refer to this one instead and specify a type of their own like >>> "localStorage", "sessionStorage", "indexedDb". >> >> The point is that apps and users should be able to communicate about >> how much disk space should be used. Why would users care which API a >> web app is using for its storage? If google.com needs 10MB to store >> my email, why should I care whether it's in indexedDB, localStorage, >> or the FileSystem? >> > > Before storing X amount of data with an API, the code requests enough > space for the storage area that API covers. That's how I understand > the use case. Then it's up to the user agent to communicate that > appropriately to the user, if applicable.
Why would we need to have the app specify "I want to store 5MB in indexedDB and 3MB in the FileSystem"? The user won't care; at most, the user needs to know "This app wants to use up 8MB of space". If the user doesn't care, why make the app make two requests? With two separate requests, you might prompt the user for the first 5MB, then immediately have to prompt them again for the next 3MB. Better just to do it all in one go: the app says "I want to store up to 8MB", then uses it in whichever APIs it likes. > APIs are web dev scope, not user scope, so storage areas need to be > differentiated. I doubt that any browser ATM shares a single quota > between all different storage types. Opera doesn't for instance. I believe that's what this proposal is trying to address. >>>> // To query how much storage is available and currently in use. >>>> void queryUsage(unsigned short storageType, >>>> UsageCallback usageCallback); >>>> >>> >>> Given that quota values are usually just preferences, hence >>> lightweight enough, this function should be sync for the sake of >>> simplicity. >> >> This doesn't request just the preference; it returns how much space is >> actually used. That might be an expensive operation, might require >> disk IO to fetch a value from an internal database, etc. > > Hum, right. But then my comment does apply to "requestQuota" no ? No > need to ping data files to store a new value for the quota, which is > usually just a pref. That's an implementation detail. Plus, storing a preference to a persistent database involves file IO, which can take an arbitrarily long time and/or fail. An async API leaves a lot of freedom for developers, so in general we try to use them for everything new outside the worker context.
