- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 16 Mar 2015 09:38:27 +0100
- To: Joshua Bell <jsbell@chromium.org>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>
On Fri, Mar 13, 2015 at 5:06 PM, Joshua Bell <jsbell@chromium.org> wrote: > A handful of us working on Chrome have been having similar discussions > around what we've been calling "durable" storage. In its simplest model a > bit granted by the user to an origin, which then requires explicit user > action before the data might be cleared under storage pressure, so it > sounds like our thinking is broadly aligned, although we're still exploring > various possibilities and their implications for permission prompts, > cleanup UI, behavior under pressure, etc. Yeah, same here, wiki page outlines a tentative plan. > Similarly, we've been trying to keep this orthogonal from quota (either the > UA's logic for assigning a quota to an origin quota, or possible > standardized quota APIs), although the UA may use similar signals for > granting permissions/assigning quota. I think we've come around in that we need to expose quota in some way to give developers some expectations to how much they can fetch and then store in "best effort" mode. But that for persistent it can be the whole disk. > (FYI, we've been using "durable" and "non-durable" to distance the > discussion from the now-loaded "temporary" vs. "persistent" terms which > surfaced in earlier API proposals, some of which are implemented in Chrome) Ah right. Current set of terms I have is "best effort" (default; fixed quota), "persistent" (requires some kind of user opt-in, probably through an API-triggered dialog, but maybe also done if you pin a tab or bookmark or some such; 'unlimited' quota), and "temporary" (exists outside of best effort/persistent, e.g. for storing social network resources, other volatile assets, requires some kind of API opt-in; fixed quota). -- https://annevankesteren.nl/
Received on Monday, 16 March 2015 08:38:53 UTC