background-fetch icon indicating copy to clipboard operation
background-fetch copied to clipboard

[FR] pass metadata from page context to SW context via bg fetch

Open joeyparrish opened this issue 7 years ago • 5 comments

For Shaka Player, the service worker will need metadata from the page in order to process the responses from the background fetch. As BG fetch is currently spec'd/implemented, it looks like we would need to abuse the "id" field for this by encoding the necessary metadata into JSON.

Is there a better option today?

If not, could we extend the API so that applications could pass some simple object as an option to BG fetch, such that the SW gets an equivalent object in the completion event?

joeyparrish avatar Nov 06 '17 17:11 joeyparrish

CC @vaage

joeyparrish avatar Nov 06 '17 18:11 joeyparrish

Additional info could be stored in IDB.

jakearchibald avatar Sep 13 '18 12:09 jakearchibald

So I suppose we could:

  1. Store BG fetch metadata in IDB
  2. Initiate BG fetch with an id that matches a record in IDB
  3. When the BG fetch is complete, load the corresponding IDB record to decide how to proceed

Is it intended that users of BG fetch compose with things like IDB to pass additional metadata? Could BG fetch be extended to allow the passage of simple, serializable metadata with a request?

joeyparrish avatar Sep 13 '18 18:09 joeyparrish

Is it intended that users of BG fetch compose with things like IDB to pass additional metadata?

It is right now. What's the biggest problem with this? The ugliness of IDB, or having to maintain the lifecycle of the data yourself?

Could BG fetch be extended to allow the passage of simple, serializable metadata with a request?

It could, but I'm a bit concerned that we keep adding extra storage for transient things like this, and maybe there's a better option.

@domenic: Do you have thoughts on this? TL;DR: We get requests to associate data with something transient such as a service worker registration, a background fetch, a background sync. We already have them for notifications – should we just keep adding more?

jakearchibald avatar Sep 14 '18 08:09 jakearchibald

What's the biggest problem with this? The ugliness of IDB, or having to maintain the lifecycle of the data yourself?

There's no giant problem with using IDB, other than the surprise of it. When we started looking into BG fetch, we didn't realize we would need to depend on some additional side-channel to accomplish what we want. Since we aren't simply putting the BG fetch results into Cache, we need to coordinate a little more between the app & the SW.

We've started planning out some of the details, and either IDB or a minor abuse of id should suffice. Thanks!

joeyparrish avatar Sep 14 '18 20:09 joeyparrish