Re: [w3ctag/design-reviews] Background fetch (#279)

Hi! Just getting my feet wet with this spec, so I apologies if my mental map is incomplete... Here's a few points of discussion I found in my first read:

The optional `downloadTotal` dictionary member misled me by it's name. I think having it called something like `doNotExceed` would better map to the use case than a pre-predicted estimate of the download total (and then leave the UI stuff to the UA to figure out (which it should know by the server responses, etc.)

The `registration.backgoundFetch` object is similar to a map in many respects. I wonder if some APIs could align better? E.g., `id`s are the keys to the various ongoing fetches. `getIds() is like `keys()`... but `set()` isn't a great match for initiating a fetch so I'm less convinced to go all the way aligning the names :). 

In the spirit of not needing to re-activate the browser code to do UI updates, I'd like to suggest we drop `updateUI` in favor of pre-declaring these strings at the time of the background fetch start. Probably you just need to care about three states: downloading (icon, title), finished (icon, title), and error/canceled (icon, title). It's not as generally powerful, but can make the UI transitions more smooth by avoiding the round-trip to the client for the various state transitions. (Also the download/upload states aren't really expected to change in an ad-hoc manner.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/279#issuecomment-434750120