On Mon, Mar 16, 2015 at 5:23 PM, Joshua Bell <jsb...@chromium.org> wrote:
> On Mon, Mar 16, 2015 at 1:38 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
>> 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.

Yeah, getting better UX/UI is a prerequisite for us as well. Firefox
has a page about:permissions today. Something like that, but more
easily accessible and without its issues would go some way towards
addressing this. And perhaps making sure the user discovers it when
they are about to run out of disk space...


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

I think that's really v2 material anyway. Another idea we had is
having named storage areas and then assigning priorities to those,
with initially the whole site being in a single area.


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

Yeah, this is also something that warrants more discussion. There's
cookies, localStorage, indexed DB, various filesystem APIs,
notifications API, history API, and indeed always the question whether
we want a nicer indexed DB / asynchronous localStorage.

Also seems like v2 material. Something we should consider after
bridging the persistence gap.


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

Yeah, I think until we'd introduce something like named storage areas
or temporary storage APIs we should treat everything under the
best-effort / persistent banner as atomic. We should probably define
that in the specification that outlines this storage architecture and
then the various storage APIs we have can tie into it.


-- 
https://annevankesteren.nl/

Reply via email to