Open annevk opened 7 years ago
Yeah, I think bgFetchJob.abort()
should be replaced with bgFetchJob.controller
. The observer should be exposed too, but depends on how we expose the observer in general.
The combined observer is kinda new, but the interface would probably be the same.
Or do you mean something more than that?
I mean that the background fetch itself is initiated through fetch()
(just like how we enabled sendBeacon()
use cases to be done through fetch()
).
I'm not sure how to do that - a single background fetch job consists of multiple fetches. Eg the background fetch for a movie could be many audio & video chunks, artwork & metadata.
Well you'd create a bunch and then hand their controllers/observers to the background process.
Might get tough if it's called while the user is offline - ideally I'd like background fetch to wait for a connection.
I thought request objects were a good representation of a non-started fetch. What were the issues with the cache API?
I think with the Cache API we've noticed that things that make sense for fetches, such as destination and whether there's a window, don't make much sense for caches, and then it's unclear whether they need to be stored, reset, etc.
I believe we also had some bigger issues, but I don't recall them.
And waiting for a connection is something that's been suggested for fetch()
too, as a coalescing primitive of sorts.
I wonder if we can reuse
fetch()
somehow. That way we don't have all the features of the Fetch API in two places. That already causes issues with the Cache API.Perhaps with the controller/observer design it would be possible to hand those off to the background process somehow?