{"action":"created","issue":{"url":"https://api.github.com/repos/slightlyoff/BackgroundSync/issues/100","labels_url":"https://api.github.com/repos/slightlyoff/BackgroundSync/issues/100/labels{/name}","comments_url":"https://api.github.com/repos/slightlyoff/BackgroundSync/issues/100/comments","events_url":"https://api.github.com/repos/slightlyoff/BackgroundSync/issues/100/events","html_url":"https://github.com/slightlyoff/BackgroundSync/issues/100","id":110962679,"number":100,"title":"one-shots via background Fetch","user":{"login":"jkarlin","id":6920902,"avatar_url":"https://avatars.githubusercontent.com/u/6920902?v=3","gravatar_id":"","url":"https://api.github.com/users/jkarlin","html_url":"https://github.com/jkarlin","followers_url":"https://api.github.com/users/jkarlin/followers","following_url":"https://api.github.com/users/jkarlin/following{/other_user}","gists_url":"https://api.github.com/users/jkarlin/gists{/gist_id}","starred_url":"https://api.github.com/users/jkarlin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jkarlin/subscriptions","organizations_url":"https://api.github.com/users/jkarlin/orgs","repos_url":"https://api.github.com/users/jkarlin/repos","events_url":"https://api.github.com/users/jkarlin/events{/privacy}","received_events_url":"https://api.github.com/users/jkarlin/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":13,"created_at":"2015-10-12T12:17:56Z","updated_at":"2015-10-26T20:58:02Z","closed_at":null,"body":"This is a continuation of #18 but focused on the one-shot case.\r\n\r\nWhat if Fetch had a 'background' option that fired a service worker event when complete (if one is registered). There would be some way to bundles fetches together (e.g., by tag) so that only one event would fire per given bundle of fetches.\r\n\r\nThere are some advantages to this:\r\n\r\n1. You could perform a background Fetch without having a registered Service Worker at all if you didn't need to perform any action post-fetch. This is useful for simply uploading changes to the server. You could then query the server on next page-load to see if it received the change.\r\n2. A service worker doesn't need to be open while the fetch is occurring. This is great because:\r\n * This reduces resource usage during download\r\n * The SW is only spun up on final success or failure. This avoids potential thrashing of starting/stopping service workers as the network connectivity goes up and down.\r\n * The UA knows exactly what resources it needs to download in the background and can display them in UX if necessary\r\n3. The API is a bit cleaner as it removes the registration step.\r\n\r\nFor privacy you'd want to restrict background fetches to be HTTPS. You would still need to put time and retry caps on them for privacy sake. For longer downloads you might require a permission or a notification (the notification could be another option to the background fetch).\r\n\r\nOpen questions:\r\n\r\n1. How long would the `backgroundFetchFinished` event get to run for? \r\n2. How would you perform a series of transactions in the background?\r\n3. Would/Should there be a way to terminate an ongoing background fetch?\r\n\r\nA simple example:\r\n\r\n```javascript\r\nDocument:\r\n\r\nfetch('https://example.com/upload', {\r\n  method: 'post', \r\n  body: 'foo', \r\n  background: true, \r\n  backgroundTag: 'outbox'\r\n})\r\n.then(function(response) {\r\n  console.log(\"Outbox sent in the foreground\");\r\n})\r\n.catch(function(err) {\r\n  console.log(\"Outbox failed to send in the foreground\");\r\n});\r\n```\r\n\r\n```javascript\r\nService Worker:\r\n\r\nself.addEventListener('backgroundFetchFinished', function(event) {\r\n  // event.response has the response if needed\r\n  var mode = event.finishedInForeground ? 'foreground' : 'background';\r\n  if (event.backgroundTag == 'outbox') {\r\n    if (event.err == null) \r\n      console.log('Outbox sent in the ' + mode);\r\n    else\r\n      console.log('Outbox failed to send in the ' + mode);\r\n  }\r\n});\r\n```"},"comment":{"url":"https://api.github.com/repos/slightlyoff/BackgroundSync/issues/comments/151282978","html_url":"https://github.com/slightlyoff/BackgroundSync/issues/100#issuecomment-151282978","issue_url":"https://api.github.com/repos/slightlyoff/BackgroundSync/issues/100","id":151282978,"user":{"login":"wibblymat","id":393358,"avatar_url":"https://avatars.githubusercontent.com/u/393358?v=3","gravatar_id":"","url":"https://api.github.com/users/wibblymat","html_url":"https://github.com/wibblymat","followers_url":"https://api.github.com/users/wibblymat/followers","following_url":"https://api.github.com/users/wibblymat/following{/other_user}","gists_url":"https://api.github.com/users/wibblymat/gists{/gist_id}","starred_url":"https://api.github.com/users/wibblymat/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wibblymat/subscriptions","organizations_url":"https://api.github.com/users/wibblymat/orgs","repos_url":"https://api.github.com/users/wibblymat/repos","events_url":"https://api.github.com/users/wibblymat/events{/privacy}","received_events_url":"https://api.github.com/users/wibblymat/received_events","type":"User","site_admin":false},"created_at":"2015-10-26T20:58:02Z","updated_at":"2015-10-26T20:58:02Z","body":"@mkruisselbrink Yes, I guess I've sort of conflated a few things here.\r\n\r\nI wanted some API that lets me say \"I have some work to do. Possibly there is a batch of similar things. Please give me an opportunity to do some background work in the future. Preferably *not* right away, but rather when things are quiet.\"\r\n\r\nBackground sync doesn't give me that, but it is *close*, so could be used to fake it. For the particular use case I mentioned the network availability isn't even that much of a problem - the task is only triggered by a successful network request being stored in the cache, so 99% of the time the sync will fire without much delay.\r\n\r\nBut that isn't really relevant. My point, which I failed to make well, was that any non-network use-cases for background sync would probably be better served by some other API around scheduling background work. `fetch(r, {background: true})` or `cache.backgroundAddAll(r)` should be able to handle the netowrk part just fine."}}