On Mon, Mar 16, 2015 at 1:38 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

> On Fri, Mar 13, 2015 at 5:06 PM, Joshua Bell <jsb...@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.


Gotcha. And thanks again for opening up this discussion!


> > 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.


I think that matches our latest discussions too...


> But that for persistent it can be
> the whole disk.
>

... and we're waffling on that one. Going that far implies that the UA does
a really good job on its own or with user interaction to respond when the
storage is indeed getting full. Mobile OSes typically provide UI to inspect
how much storage is in use and clear apps and/or portions of their storage.
IMHO, we need to fully develop that UX in the UA before I'd be comfortable
letting sites easily consume the whole disk.

But we realize that artificially capping disk usage is a gap between web
and native, and so solving that problem is high priority for us. And I
don't think there are spec/standards implications here so we can move fast
on the UA side, as long as we spec that QuotaExceededError can happen on
various operations regardless of permissions, because even unlimited quota
can be constrained by physical limits.

> (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).
>
>
If I'm reading the wiki page correctly, I'm intrigued by the "temporary"
proposal. To confirm, you're envisioning a completely new lightweight
storage API and there's no implied addition to the other storage APIs? If
so... well, pros and cons. I'm not a huge fan of adding Yet Another Storage
API. On the other hand, I'd rather do that then "fork" the existing storage
APIs into temp/persistent and try and shoehorn priorities into those.

If it helps I did a thought experiment a while ago on "what would a
stripped-down, Promise-based IDB-lite look like?" at
https://gist.github.com/inexorabletash/c8069c042b734519680c - it doesn't
have the priority scheme, but that would be easy to add at the 'open' entry
point.

...

One thing we should discuss under the storage umbrella is how atomically we
treat all storage for an origin. Customers we've talked to acknowledge the
reality that even "durable" storage can be wiped in the face of user action
(e.g. via settings UI to clear cookies etc) or file corruption. One of the
situations they're concerned about is dealing with partial clearing of
data, e.g. Indexed DB databases are present but the SW cache has been
wiped, or vice versa. Currently, for quota-based storage eviction, we evict
an origin's entire storage at once - that's easiest for sites to reason
about, since it matches the "first time user" or "returning user on new
device" scenarios that must already be supported. If we're taking a step
back to think of storage as a whole, we may want to provide more spec-level
assurance in this area.


>
> --
> https://annevankesteren.nl/
>

Reply via email to