- From: Kinuko Yasuda <kinuko@chromium.org>
- Date: Fri, 4 Feb 2011 14:07:31 +0900
- To: Charles Pritchard <chuck@visc.us>, Shawn Wilsher <sdwilsh@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, ericu@google.com, Joćo Eiras <joao.eiras@gmail.com>
- Cc: public-webapps@w3.org
Thanks for all of your feedbacks. So it seems like one of the main discussion topic is whether we want to have "shared quota" between multiple storage mechanisms (per origin, per persistent/temporary storage class) or not. On Fri, Feb 4, 2011 at 9:33 AM, Jonas Sicking <jonas@sicking.cc> wrote: > I think the idea with this spec is that it *requires* that > implementations share quota between its various storage mechanisms. As > an implementor I think this is a good idea. Yes, the primary idea of the proposal is to have a shared quota. (I should have noted it more explicitly.) I think and believe that in most cases users or webapps would see few point in having differentiated quota for different storages, as long as they all use the same persistent storage (i.e. disk) and belong to the same origin (=~ same webapp). As for localStorage, as Charles and Glenn expressed their concerns it might be better to take it off the table for now. Or I would simply say we should make it a "temporary-only" offline storage in the quota terminology, and requesting persistent quota should have no impact on localStorage quotas. On Fri, Feb 4, 2011 at 6:56 AM, Glenn Maynard <glenn@zewt.org> wrote: > One possible approach: rather than having a single implementation of > StorageInfo, each storage API implements the interface; LocalFileSystem, > LocalFileSystemSync, IDBDatabase, Storage. This way, the API doesn't need > to know how to specify a particular category of each type (storageType goes > away), and the question of separated quotas is improved. If we want to make the quota API treat each API differently this would make a lot sense, but I'm not fully convinced by the idea. Putting aside the localStorage for now, do you still see significant issues in having a sshared single quota? Also let me note that this API does not and should not guarantee that the app can actually *write* that amount of data into the storage, even after the quota is granted, and the UA could still stop an API to write further even if it's within the quota. Thanks, Kinuko
Received on Friday, 4 February 2011 05:08:22 UTC