Integration with service workers

[marcoscaceres]

Specify the relationship between this spec and service workers.

Or get service worker to define the member and hook in through the extension point in the spec...

[marcoscaceres]

Rough proposal:

{
    "service_workers": [{
        "src": "foo.js",
        "scope": "/allthefoo*"
    }, {
        "src": "bar.js",
        "scope": "/the/bar/just-the-bar/"
    }]
}

[marcoscaceres]

@slightlyoff proposes just doing:

{
"service_worker": "...", 
"service_worker_options": { ... }
}

That keeps it simple, but limits only one SW registration per manifest.

[domenic]

What about:

{
  "service_worker": {
    "src": "foo.js",
    "scope": "/allthefoo"
  }
}

with the option of adding "service_workers" later if it turns out to be a valid use case?

Just cosmetically, I'm not a fan of two separate options for a single concept. But that's certainly minor.

[tobie]

I don't really understand why it's OK to have:

{
    "service_worker": { "src": "foo.js", "scope": "/allthefoo" }
}

But not:

navigator.serviceWorker.register({ src: "foo.js", scope: "/allthefoo" });

[tobie]

As mentioned in #manifest, I'd be very much in favor of being very lenient with input à la npm package.json, but I'm concerned this might be 1) hard to spec, 2) source of interop issues. Thoughts?

[marcoscaceres]

So, I'm going to spec what @domenic suggested. I trust @slightlyoff's judgement about only having one service worker allowed to be declared per manifest - though I find it somewhat limiting. On the other hand, I can see that it plays a nice conceptual "master service worker" role even if in practice it's just another service worker.

@tobie, sorry, discussion about navigator.serviceWorker.register is out of scope for this bug.

[tobie]

@tobie https://github.com/tobie, sorry, discussion about
navigator.serviceWorker.register is out of scope for this bug

Yeah, sorry. That was a poorly formulated way of asking for consistency
between both APIs.

[marcoscaceres]

Spec'ing it is not that hard. But it will definitely make things more complicated as it makes testing and interop way more of a challenge. I would be inclined to initially keep this strict and see how we go. We can always allow more types if we find a lot of people making authoring errors.

[marcoscaceres]

Going to get scope #114 working independently of SWs first. Still probably about 1-2 year till SWs are stable.