Hints in beforeevicted to let the SW of a web app pick among several house cleaning options?

[KenjiBaheux]

I'm assuming that the intent of onbeforeevicted is to notify a Service Worker that the system is under storage pressure and is gently asking for freeing up resources before it wipes out all the Caches.

The beforeevicted event hasn't been spec yet but I was thinking about use cases. For instance, an app should know what's critical, vs. what's important, vs. what's secondary. Concretely, you can imagine that an airline app might decide to either shed away everything except what's needed to show an electronic boarding pass, or everything except what's needed to display hotel and directions as well as the electronic boarding pass.

A game might want to evict the bare minimum (e.g. completed game levels, high res assets...). Similarly, a video rental app might want to evict already watched episodes (1-3) and/or evict unseen episodes from the tail (the last 2 episodes, 7 and 8).

Basically, if the event for a given SW had hints about how much pressure there is and how much this particular SW is contributing to it, a web developer could code an eviction strategy that offers the right balance between what is being asked while maintaining expected levels of user experience and minimizing the risk of being wiped-out (e.g. the user can still check-in with his electronic boarding pass, the user can still play new levels and watch new episodes of his favorite show on his flight).

Thoughts?

[annevk]

Before making this more complicated I think we should first test whether it works at all.

[KenjiBaheux]

Ultimately, I care about the use cases and delivering a great user experience. I don't mind if the solution takes another form.

That being said, whether or not the use cases are reasonable is entirely up for debate.

[slightlyoff]

A before-eviction event is the simplest thing we could come up with in many months of trying. It gives the UA ultimate freedom in deciding if and when to request storage back and from whom. These are important properties.

All we need to add to the event to get this done is a spaceRequested property. When Kinuko and I last looked, this was the missing link in conveying pressure.

@annevk: when you say "more complicated", what are you referring to?

[annevk]

I was thinking that just having the event would be enough for now. I don't really see how spaceRequested can help since applications will have completely different storage models and ideas about persistence. So if you need more disk space, how would you distribute that request over the origins that use storage? Seems too early to tell.

[kinu]

How to distribute space request over origins is not a simple question, but I want to pursue this idea a bit more. If we just let apps to guess and decide how much data to delete it may end up with some gaming, e.g. conservative apps may delete as much data as possible to make their survival rate higher while greedy apps may just get more space. I think UA could probably do a modest (if not better) job to distribute available space over apps using their past usage data.

Also if we consider spaceRequested a contract there could be a huge difference between "if you delete X amount of data we can keep your remaining data" and "we're on resource shortage, please delete some, though we may still delete your entire data". And I think that's what developers really want, where they can flexibly decide how persistent each of their data item should be depending on the space need.

[annevk]

E.g. one thing that is unclear to me how this would play out in a scenario where one application uses several gigabytes (to store music files I use every day) versus other applications that require a lot less storage (for which persistence is less important). Or versus other applications that also store several gigabytes, but I don't really rely on the persistence as a user.

[wanderview]

The onbeforeevicted and onevicted events are currently listed on the ServiceWorkerGlobalScope. Does this make sense given that we now have caches in windows and other Workers? Should these events be on caches instead?

Also, it seems for this to be useful, content needs some way to tell how much space Cache is being used (#587).

Finally, should all this instead be on some quota interface? It seems storage space used should include things like IDB, etc.

[inexorabletash]

Since it's not already on this thread, @kinu's draft spec is at: https://kinu.github.io/quota-api/Overview.html

@wanderview - re: "storage space used should include things like IDB, etc" - yep, it applies to more than just Cache storage. We're envisioning that eviction applies to the entire origin, based on storage pressure, heuristics, or user action (e.g. UI for "clear stored data") - otherwise we leave web apps in an inconsistent state. Exposing it to the SW is a way to let the origin participate either before or after the fact, without relying on a page being open.

(I'm still coming up to speed here, so corrections appreciated)

[wanderview]

Thanks! I'll post any further questions over there.

[kinu]

@annevk Right those are tough questions. I imagine the UA could at least relate the frequency of app usage to the importance of its data. If the music app is used every day the UA will unlikely choose to evict its data as far as it can reclaim enough space by evicting other apps. On the other hand it'd be very hard for either UA or app to tell how important the data persistence is to the user, I suppose we may need some UI for it to play out best.

@wanderview Yes, as @inexorabletash mentioned we're thinking about making it as a part of quota management and we think the storage space should include things like IDB etc.

[annevk]

Yeah, that is why it's unclear to me that such a property is going to help. E.g. on my phone all storage is used by photos and videos I took, and music. I don't use those applications daily, but I would not want any of it removed.

[jakearchibald]

Or tripit. I rarely use the app but the stored data (and push messages) is of vital importance.

I can't wrap my head around spaceRequested. If it's the total the device needs to recover, it could be greater than the total amount you're storing. If it's the total the device needs to recover divided between the origins as some percentage of their usage, could you end up being nuked even if you release the requested amount of data (due to other origins not releasing enough data)?

Is it better to go with https://github.com/slightlyoff/StorageDurability and let the user decide what to keep/remove?

[kinu]

Yeah maybe. I was thinking how eviction could work with and without it, and I started to feel that we could probably go without spaceRequested at least in v1. If an app wants some guarantee for data persistence the app can use https://github.com/slightlyoff/StorageDurability, and if storage situation becomes really tight even after firing beforeevict and evicting non-durable apps the UA can show some UI to let the user decide what to keep/remove.