Integration with service workers #161

Closed
marcoscaceres opened this Issue Feb 25, 2014 · 107 comments

Comments

Projects
None yet
@marcoscaceres
Member

marcoscaceres commented Feb 25, 2014

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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jun 13, 2014

Member

Rough proposal:

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

marcoscaceres commented Jun 13, 2014

Rough proposal:

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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jun 13, 2014

Member

@slightlyoff proposes just doing:

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

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

Member

marcoscaceres commented Jun 13, 2014

@slightlyoff proposes just doing:

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

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

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jun 13, 2014

Contributor

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.

Contributor

domenic commented Jun 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tobie

tobie Jun 13, 2014

Member

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" });
Member

tobie commented Jun 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tobie

tobie Jun 13, 2014

Member

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?

Member

tobie commented Jun 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jun 16, 2014

Member

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.

Member

marcoscaceres commented Jun 16, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tobie

tobie Jun 16, 2014

Member

@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.

Member

tobie commented Jun 16, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jun 17, 2014

Member

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.

Member

marcoscaceres commented Jun 17, 2014

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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Nov 5, 2014

Member

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

Member

marcoscaceres commented Nov 5, 2014

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

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Dec 18, 2014

Member

I'm still wondering if we can live without having an SW declared in the manifest at all. I'm probably missing something, but I'm still unsure as to the value of having a SW declared in the manifest is instead of, say, the start_url?

Member

marcoscaceres commented Dec 18, 2014

I'm still wondering if we can live without having an SW declared in the manifest at all. I'm probably missing something, but I'm still unsure as to the value of having a SW declared in the manifest is instead of, say, the start_url?

@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Jan 5, 2015

Collaborator

Well that would mean that the service worker might not have been installed when the app has been added to the launcher and thus might not work offline until launched second time.

With it in the manifest, the UA could make sure that the service worker is installed (which in return could depend on fetching of resources to make offline work etc) when added to the home screen and fail adding it in case the service worker couldn't be installed.

I think that it makes sense

Collaborator

kenchris commented Jan 5, 2015

Well that would mean that the service worker might not have been installed when the app has been added to the launcher and thus might not work offline until launched second time.

With it in the manifest, the UA could make sure that the service worker is installed (which in return could depend on fetching of resources to make offline work etc) when added to the home screen and fail adding it in case the service worker couldn't be installed.

I think that it makes sense

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jan 8, 2015

Member

Well that would mean that the service worker might not have been installed when the app has been added to the launcher and thus might not work offline until launched second time.

True. But there is no guarantee that an app will ever be installed at all, and the app should work offline regardless (because 1. the UA might not support manifests, and 2. the user declined to install it, but still wants to access the app when offline - for example, the user is on vacation, they visited a restaurant's website, restarted their phone, and now want to view the website but offline).

In other words, installing an application should never be a precondition for getting offline functionality.

With it in the manifest, the UA could make sure that the service worker is installed (which in return could depend on fetching of resources to make offline work etc) when added to the home screen and fail adding it in case the service worker couldn't be installed.

I think that it makes sense

I agree. It makes sense. But this is predicated on some assumptions that might not hold in practice: the service worker might not actually provide any offline capabilities. The service worker, and its cache, might have been evicted. Having a service worker in the manifest shouldn't grant that service worker any additional rights (or longevity) when compared to a SW declared in script. Otherwise, we will just end up with everyone declaring SWs in the manifest and then problems if the manifest doesn't get used by the UA.

The more I think about this, the more I want to separate them: I feel like what the manifest provides and what SWs provide are separate concerns.

Member

marcoscaceres commented Jan 8, 2015

Well that would mean that the service worker might not have been installed when the app has been added to the launcher and thus might not work offline until launched second time.

True. But there is no guarantee that an app will ever be installed at all, and the app should work offline regardless (because 1. the UA might not support manifests, and 2. the user declined to install it, but still wants to access the app when offline - for example, the user is on vacation, they visited a restaurant's website, restarted their phone, and now want to view the website but offline).

In other words, installing an application should never be a precondition for getting offline functionality.

With it in the manifest, the UA could make sure that the service worker is installed (which in return could depend on fetching of resources to make offline work etc) when added to the home screen and fail adding it in case the service worker couldn't be installed.

I think that it makes sense

I agree. It makes sense. But this is predicated on some assumptions that might not hold in practice: the service worker might not actually provide any offline capabilities. The service worker, and its cache, might have been evicted. Having a service worker in the manifest shouldn't grant that service worker any additional rights (or longevity) when compared to a SW declared in script. Otherwise, we will just end up with everyone declaring SWs in the manifest and then problems if the manifest doesn't get used by the UA.

The more I think about this, the more I want to separate them: I feel like what the manifest provides and what SWs provide are separate concerns.

@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Jan 8, 2015

Collaborator

The offline etc won't depend on the manifest support, it just means that the first launch after added to the home screen will already have the service worker ready and if the app developer decides, work offline, have push messages etc. Without this, the user might first have it on second launch.

Is there another way do fix that issue? Another option would be to have some event to be called when an app is added to the home screen, which then would allow the developer to ensure the SW is installed, or fail "installing" the app.

Collaborator

kenchris commented Jan 8, 2015

The offline etc won't depend on the manifest support, it just means that the first launch after added to the home screen will already have the service worker ready and if the app developer decides, work offline, have push messages etc. Without this, the user might first have it on second launch.

Is there another way do fix that issue? Another option would be to have some event to be called when an app is added to the home screen, which then would allow the developer to ensure the SW is installed, or fail "installing" the app.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jan 9, 2015

Member

The offline etc won't depend on the manifest support, it just means that the first launch after added to the home screen will already have the service worker ready and if the app developer decides, work offline, have push messages etc. Without this, the user might first have it on second launch.

My working assumption is that installing just reopens the browser but, possibly, in a different display mode. Can you help me understand the issue a bit? This is what I assume happens:

  1. user goes to https://foo.com.
  2. foo.com registers a SW.
  3. Time passes, pages are reloaded. SW is happily doing its thing.
  4. Browser or user decides "this is install worthy! I'm going to keep this".
  5. foo.com is added to homescreen.
  6. foo.com is relaunched - but new display mode is applied. SW is still doing its thing. Everyone is happy?

What am I missing? :(

Member

marcoscaceres commented Jan 9, 2015

The offline etc won't depend on the manifest support, it just means that the first launch after added to the home screen will already have the service worker ready and if the app developer decides, work offline, have push messages etc. Without this, the user might first have it on second launch.

My working assumption is that installing just reopens the browser but, possibly, in a different display mode. Can you help me understand the issue a bit? This is what I assume happens:

  1. user goes to https://foo.com.
  2. foo.com registers a SW.
  3. Time passes, pages are reloaded. SW is happily doing its thing.
  4. Browser or user decides "this is install worthy! I'm going to keep this".
  5. foo.com is added to homescreen.
  6. foo.com is relaunched - but new display mode is applied. SW is still doing its thing. Everyone is happy?

What am I missing? :(

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jan 9, 2015

Member

Let me put it a different way: let's see how we go initially without having this in the spec... at least allow Chrome and Gecko to catch up by supporting the same basic set of features.

It's going to be a few years before service workers are in all browsers. We have a better chance of enabling the manifest's basic functionality across a larger set of browsers if we don't put in a dependency on SWs at this point (IMO).

Unless people thing this is a critical feature, I would suggest we drop it for now.

Member

marcoscaceres commented Jan 9, 2015

Let me put it a different way: let's see how we go initially without having this in the spec... at least allow Chrome and Gecko to catch up by supporting the same basic set of features.

It's going to be a few years before service workers are in all browsers. We have a better chance of enabling the manifest's basic functionality across a larger set of browsers if we don't put in a dependency on SWs at this point (IMO).

Unless people thing this is a critical feature, I would suggest we drop it for now.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jan 11, 2015

Member

Not hearing any objections, I'm closing for now.

Member

marcoscaceres commented Jan 11, 2015

Not hearing any objections, I'm closing for now.

@benfrancis

This comment has been minimized.

Show comment
Hide comment
@benfrancis

benfrancis Jan 14, 2015

@marcoscaceres I'd like to propose re-opening this, I didn't realise it had been closed. I think it's fine if some implementations don't get around to implementing this property for a while, nobody supports the scope property yet either.

that would mean that the service worker might not have been installed when the app has been added to the launcher and thus might not work offline until launched second time.

I think this is the key point. The service_worker property would not be the only way for a given Service Worker to be registered, it would just be a way of ensuring that it gets registered the moment a user installs an app. Otherwise, the app will only work offline the second time the app is launched.

I think being able to use a Service Worker as an installation script for an app by hooking into the worker's "install" event could be hugely powerful. Not just for downloading resources of the app into a cache for offline use, but for all kinds of purposes.

@slightlyoff, what do you think?

@marcoscaceres I'd like to propose re-opening this, I didn't realise it had been closed. I think it's fine if some implementations don't get around to implementing this property for a while, nobody supports the scope property yet either.

that would mean that the service worker might not have been installed when the app has been added to the launcher and thus might not work offline until launched second time.

I think this is the key point. The service_worker property would not be the only way for a given Service Worker to be registered, it would just be a way of ensuring that it gets registered the moment a user installs an app. Otherwise, the app will only work offline the second time the app is launched.

I think being able to use a Service Worker as an installation script for an app by hooking into the worker's "install" event could be hugely powerful. Not just for downloading resources of the app into a cache for offline use, but for all kinds of purposes.

@slightlyoff, what do you think?

@benfrancis

This comment has been minimized.

Show comment
Hide comment
@benfrancis

benfrancis Jan 14, 2015

My working assumption is that installing just reopens the browser but, possibly, in a different display mode. Can you help me understand the issue a bit?

I don't think this is quite how it would work on all operating systems. There's no guarantee that things like cookies, IndexedDB databases and Service Worker registrations would survive the transition from the browsing context in the browser app to the application context in the OS. The OS might even use a different rendering engine to the browser the app was installed from.

My working assumption is that installing just reopens the browser but, possibly, in a different display mode. Can you help me understand the issue a bit?

I don't think this is quite how it would work on all operating systems. There's no guarantee that things like cookies, IndexedDB databases and Service Worker registrations would survive the transition from the browsing context in the browser app to the application context in the OS. The OS might even use a different rendering engine to the browser the app was installed from.

@tobie

This comment has been minimized.

Show comment
Hide comment
@tobie

tobie Jan 14, 2015

Member

Removed my knee-jerk reaction as it's a distraction to this thread. Apologies.

Member

tobie commented Jan 14, 2015

Removed my knee-jerk reaction as it's a distraction to this thread. Apologies.

@marcoscaceres marcoscaceres reopened this Jan 15, 2015

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jan 15, 2015

Member

Maybe @jakearchibald can help here with an illustrative example... or at least tell me how wrong I am :)

@marcoscaceres I'd like to propose re-opening this, I didn't realise it had been closed. I think it's fine if some implementations don't get around to implementing this property for a while, nobody supports the scope property yet either.

The problem is not one of support, it's about use case and functionality.

I think this is the key point. The service_worker property would not be the only way for a given Service Worker to be registered, it would just be a way of ensuring that it gets registered the moment a user installs an app. Otherwise, the app will only work offline the second time the app is launched.

This is the bit I really don't understand - and I need some enlightenment here. As far as I can see, it means throwing away all the registration machinery that a developer gets with navigator.serviceWorker.register(). Would they, and us, really want to do that?

Additionally, there is no guarantee that the SW will be registered/ready in time before the user re-launches the app. The same machinery that governs installation of SW still applies, so installation can fail or be rejected for all the standard reasons. A user could also open the application while the UA is still waiting for the SW script to d/l, etc.... unless the web application is blocked from launching until the SW becomes ready, which might also be kinda sad (as it might never finish installing).

I don't understand why developers wouldn't just do the following prior to installation (or what advantage the manifest brings over just doing the following prior to installation of the web app):

//Register the SW when the page first loads. Done. 
if ('serviceWorker' in navigator) {
  window.addEventListener("DOMContentLoaded", (e) => {
    navigator.serviceWorker.register('/app/sw.js', {
      scope: '/app/'
    })
    .then(reg => console.log('Yey!', reg))
    .catch(err => console.log('Boo!', err));
  });
}

I'm still hoping someone can explain this to me. If possible, a real-life example would be great.

I think being able to use a Service Worker as an installation script for an app by hooking into the worker's "install" event could be hugely powerful. Not just for downloading resources of the app into a cache for offline use, but for all kinds of purposes.

Sure, I agree: but that's a general statement that applies to service workers, and the apps that use them, at large. By having this in manifest, what you are implying is that those capabilities only be made available to manifest-supporting user agents (as it would be only those user agents that would install that particular SW). At least, there is a risk that a developer could unwittingly exclusively target manifest supporting UAs - and I think that's pretty sad.

Member

marcoscaceres commented Jan 15, 2015

Maybe @jakearchibald can help here with an illustrative example... or at least tell me how wrong I am :)

@marcoscaceres I'd like to propose re-opening this, I didn't realise it had been closed. I think it's fine if some implementations don't get around to implementing this property for a while, nobody supports the scope property yet either.

The problem is not one of support, it's about use case and functionality.

I think this is the key point. The service_worker property would not be the only way for a given Service Worker to be registered, it would just be a way of ensuring that it gets registered the moment a user installs an app. Otherwise, the app will only work offline the second time the app is launched.

This is the bit I really don't understand - and I need some enlightenment here. As far as I can see, it means throwing away all the registration machinery that a developer gets with navigator.serviceWorker.register(). Would they, and us, really want to do that?

Additionally, there is no guarantee that the SW will be registered/ready in time before the user re-launches the app. The same machinery that governs installation of SW still applies, so installation can fail or be rejected for all the standard reasons. A user could also open the application while the UA is still waiting for the SW script to d/l, etc.... unless the web application is blocked from launching until the SW becomes ready, which might also be kinda sad (as it might never finish installing).

I don't understand why developers wouldn't just do the following prior to installation (or what advantage the manifest brings over just doing the following prior to installation of the web app):

//Register the SW when the page first loads. Done. 
if ('serviceWorker' in navigator) {
  window.addEventListener("DOMContentLoaded", (e) => {
    navigator.serviceWorker.register('/app/sw.js', {
      scope: '/app/'
    })
    .then(reg => console.log('Yey!', reg))
    .catch(err => console.log('Boo!', err));
  });
}

I'm still hoping someone can explain this to me. If possible, a real-life example would be great.

I think being able to use a Service Worker as an installation script for an app by hooking into the worker's "install" event could be hugely powerful. Not just for downloading resources of the app into a cache for offline use, but for all kinds of purposes.

Sure, I agree: but that's a general statement that applies to service workers, and the apps that use them, at large. By having this in manifest, what you are implying is that those capabilities only be made available to manifest-supporting user agents (as it would be only those user agents that would install that particular SW). At least, there is a risk that a developer could unwittingly exclusively target manifest supporting UAs - and I think that's pretty sad.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Jan 15, 2015

I haven't really been involved in this proposal so far, so I'm coming at this fresh, apologies if I'm retreading old ground.

Uses

  • If the added-to-home-screen site has a different instance of origin storage & ServiceWorkers, a declaration in the manifest means these storage instances can be populated by the SW at the time the user adds to home screen, rather than on first run. However, this would be better fixed by maintaining existing origin storage & SW. Losing/resetting data on adding-to-home-screen sounds like a bug
  • The browser could provide a system to add sites to home screen without actually visiting them, eg a web app store. In this case it's desirable for a SW to set up before first visit. Also, the lifecycle of the SW can be used by the app store to indicate installation progress or signal failure
  • The declarative SW form could be used by search engines to hint at app-like capability, although it's a very weak signal

Cons

I'm assuming that the SW details in the manifest are only actually used on add-to-homescreen or similar, as in not during regular page load.

  • Duplication. You'll still need registration in the page

The only usage that feels particularly strong to me is the 2nd one, enabling an install flow for app-store like things. Personally I'd love to see search engines provide this functionality. Given Mozilla has a web app store, is it something they're keen on?

I haven't really been involved in this proposal so far, so I'm coming at this fresh, apologies if I'm retreading old ground.

Uses

  • If the added-to-home-screen site has a different instance of origin storage & ServiceWorkers, a declaration in the manifest means these storage instances can be populated by the SW at the time the user adds to home screen, rather than on first run. However, this would be better fixed by maintaining existing origin storage & SW. Losing/resetting data on adding-to-home-screen sounds like a bug
  • The browser could provide a system to add sites to home screen without actually visiting them, eg a web app store. In this case it's desirable for a SW to set up before first visit. Also, the lifecycle of the SW can be used by the app store to indicate installation progress or signal failure
  • The declarative SW form could be used by search engines to hint at app-like capability, although it's a very weak signal

Cons

I'm assuming that the SW details in the manifest are only actually used on add-to-homescreen or similar, as in not during regular page load.

  • Duplication. You'll still need registration in the page

The only usage that feels particularly strong to me is the 2nd one, enabling an install flow for app-store like things. Personally I'd love to see search engines provide this functionality. Given Mozilla has a web app store, is it something they're keen on?

@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Jan 15, 2015

Collaborator

im more thinking whether it might be more interesting and future proof to be able to run some JS code when "installing/adding to homescreen". This code should then succeed or fail (meaning failure would mean failure to add to homescreen). That code could then install the service worker (or fail)

Collaborator

kenchris commented Jan 15, 2015

im more thinking whether it might be more interesting and future proof to be able to run some JS code when "installing/adding to homescreen". This code should then succeed or fail (meaning failure would mean failure to add to homescreen). That code could then install the service worker (or fail)

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Jan 15, 2015

I thought about that too, my brain did this:

  1. Actually, it'd be nice to run any code as part of install
  2. Hmm, but that gets tough when it comes to async code
  3. We need something to signal completion, like a callback or a promise
  4. Putting this code in json, it should go in another file
  5. Oh shit I just reinvented ServiceWorker

I thought about that too, my brain did this:

  1. Actually, it'd be nice to run any code as part of install
  2. Hmm, but that gets tough when it comes to async code
  3. We need something to signal completion, like a callback or a promise
  4. Putting this code in json, it should go in another file
  5. Oh shit I just reinvented ServiceWorker
@benfrancis

This comment has been minimized.

Show comment
Hide comment
@benfrancis

benfrancis Jan 15, 2015

Install from the app

marcoscaceres wrote:

As far as I can see, it means throwing away all the registration machinery that a developer gets with navigator.serviceWorker.register(). Would they, and us, really want to do that?

What do you think would be thrown away? Would this not just be a declarative equivalent of navigator.serviceWorker.register() which in fact calls that method under the hood?

I don't understand why developers wouldn't just do the following prior to installation (or what advantage the manifest brings over just doing the following prior to installation of the web app) [register service worker on page load].

That's a fair point. I would say:

  • We should consider the case where service worker registrations don't survive the install process. I agree this could be considered a bug, but it may end up being quite common. Would Firefox on Android, Chrome on iOS or even Chrome on Android be able to guarantee this? Right now even Firefox OS uses a completely separate "data jar" for an installed app than for browser tabs for privacy reasons.
  • I think you could argue that an app developer choosing to only register a Service Worker if the user explicitly "installs" the app to their device could be considered a valid design choice. I suspect proponents of Service Workers would argue that everything should use Service Workers by default, but perhaps that choice could be left to the developer?

An example use case might be the Pinned Apps design concept where all web apps can be used as a one-off in the browser without being installed, but the user may explicitly pin an app they want to persist to their device and use separately from the browser https://wiki.mozilla.org/FirefoxOS/Pinned_Apps

Install from an app store

jakearchibald wrote:

enabling an install flow for app-store like things. Personally I'd love to see search engines provide this functionality. Given Mozilla has a web app store, is it something they're keen on?

I don't think the current Web Manifest spec serves this use case very well today as there's no API for a web page to install an app from another origin. The user agent has to detect the manifest and give the user the option to "add to home" or similar when they are already using the app in the browser. It may be that due to a quirk of the way Web Manifest is implemented in Gecko it's actually possible to use the mozApps installation API with a Web Manifest, but that would be a proprietary API and is likely to go away.

This might be a use case which gets addressed in future, but right now I don't think it necessarily makes a good argument for this feature.

Install from a product page

Something this could potentially be useful for is if the user installs the app from the app's product page on the same origin as the app. For example, https://evernote.com/ might not register the Service Worker, but https://evernote.com/Home.action would. Installing the app from https://evernote.com/ could therefore register the Service Worker declared in the manifest.

Uninstall

Another use case I just thought of is that when a user uninstalls the app from their operating system, the service_worker property could perhaps also be used to unregister the Service Worker.

Installation script

Some of the use cases described above may be a little weak, but I do think that the ability for a developer to use a Service Worker as an installation script for their app in general could be very powerful. There are all kinds of things a developer might want to trigger when the user installs their app other than populating a cache - from populating default data in a database or calling home to measure install metrics, to simply thanking the user.

Install from the app

marcoscaceres wrote:

As far as I can see, it means throwing away all the registration machinery that a developer gets with navigator.serviceWorker.register(). Would they, and us, really want to do that?

What do you think would be thrown away? Would this not just be a declarative equivalent of navigator.serviceWorker.register() which in fact calls that method under the hood?

I don't understand why developers wouldn't just do the following prior to installation (or what advantage the manifest brings over just doing the following prior to installation of the web app) [register service worker on page load].

That's a fair point. I would say:

  • We should consider the case where service worker registrations don't survive the install process. I agree this could be considered a bug, but it may end up being quite common. Would Firefox on Android, Chrome on iOS or even Chrome on Android be able to guarantee this? Right now even Firefox OS uses a completely separate "data jar" for an installed app than for browser tabs for privacy reasons.
  • I think you could argue that an app developer choosing to only register a Service Worker if the user explicitly "installs" the app to their device could be considered a valid design choice. I suspect proponents of Service Workers would argue that everything should use Service Workers by default, but perhaps that choice could be left to the developer?

An example use case might be the Pinned Apps design concept where all web apps can be used as a one-off in the browser without being installed, but the user may explicitly pin an app they want to persist to their device and use separately from the browser https://wiki.mozilla.org/FirefoxOS/Pinned_Apps

Install from an app store

jakearchibald wrote:

enabling an install flow for app-store like things. Personally I'd love to see search engines provide this functionality. Given Mozilla has a web app store, is it something they're keen on?

I don't think the current Web Manifest spec serves this use case very well today as there's no API for a web page to install an app from another origin. The user agent has to detect the manifest and give the user the option to "add to home" or similar when they are already using the app in the browser. It may be that due to a quirk of the way Web Manifest is implemented in Gecko it's actually possible to use the mozApps installation API with a Web Manifest, but that would be a proprietary API and is likely to go away.

This might be a use case which gets addressed in future, but right now I don't think it necessarily makes a good argument for this feature.

Install from a product page

Something this could potentially be useful for is if the user installs the app from the app's product page on the same origin as the app. For example, https://evernote.com/ might not register the Service Worker, but https://evernote.com/Home.action would. Installing the app from https://evernote.com/ could therefore register the Service Worker declared in the manifest.

Uninstall

Another use case I just thought of is that when a user uninstalls the app from their operating system, the service_worker property could perhaps also be used to unregister the Service Worker.

Installation script

Some of the use cases described above may be a little weak, but I do think that the ability for a developer to use a Service Worker as an installation script for their app in general could be very powerful. There are all kinds of things a developer might want to trigger when the user installs their app other than populating a cache - from populating default data in a database or calling home to measure install metrics, to simply thanking the user.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Jan 15, 2015

@benfrancis

https://evernote.com/ might not register the Service Worker, but https://evernote.com/Home.action would

Why would you want to offer ServiceWorker features to home-screen-launched but not browser visited?

Another use case I just thought of is that when a user uninstalls the app from their operating system, the service_worker property could perhaps also be used to unregister the Service Worker.

That doesn't feel right if the browser & home-screen-thing share storage and SW. I wouldn't expect removing a home screen icon to remove features I previously had in the browser, maybe even features that were registered in the browser. If the home-screen-thing has a different storage & SW, the system can detect which origins the user has icons for and remove storage & SW without the manifest.

calling home to measure install metrics

How would you tell the difference between a normal SW install, and one triggered from add-to-homescreen?

@benfrancis

https://evernote.com/ might not register the Service Worker, but https://evernote.com/Home.action would

Why would you want to offer ServiceWorker features to home-screen-launched but not browser visited?

Another use case I just thought of is that when a user uninstalls the app from their operating system, the service_worker property could perhaps also be used to unregister the Service Worker.

That doesn't feel right if the browser & home-screen-thing share storage and SW. I wouldn't expect removing a home screen icon to remove features I previously had in the browser, maybe even features that were registered in the browser. If the home-screen-thing has a different storage & SW, the system can detect which origins the user has icons for and remove storage & SW without the manifest.

calling home to measure install metrics

How would you tell the difference between a normal SW install, and one triggered from add-to-homescreen?

@benfrancis

This comment has been minimized.

Show comment
Hide comment
@benfrancis

benfrancis Jan 15, 2015

Why would you want to offer ServiceWorker features to home-screen-launched but not browser visited?

My point here was just that this could be a use case similar to the app store use case where the user may install the app before having used it, then it would be nice if the Service Worker was already registered the first time they launch the app. That wouldn't prevent the same Service Worker from being used in the browser if the user navigated to https://evernote.com/Home.action.

If the home-screen-thing has a different storage & SW, the system can detect which origins the user has icons for and remove storage & SW without the manifest.

Not necessarily, there could be multiple apps installed from the same origin. I don't think the OS would necessarily know which Service Workers to unregister.

How would you tell the difference between a normal SW install, and one triggered from add-to-homescreen?

That's a fair point. I guess the developer would have to specify a separate Service Worker in the manifest as an installation script, which then in turn registers other Service Workers which would also be registered in the browser.

I guess the question is really whether there's enough value in:

  • Being able to specify a Service Worker in the manifest to be registered at install time before an application context is created, vs. relying on the Service Worker being registered before installation via a browsing context and surviving the transition to an application context, otherwise risk that the app might not work offline etc. the first time it is launched.
  • An install event which is fired at install time.
  • Whether having a Service Worker which is only registered when the app is installed, or having a different Service Worker registered when the app is installed, is a valid design choice.

As you say, a general install event could be implemented separately if considered useful, but might just re-invent Service Workers.

Why would you want to offer ServiceWorker features to home-screen-launched but not browser visited?

My point here was just that this could be a use case similar to the app store use case where the user may install the app before having used it, then it would be nice if the Service Worker was already registered the first time they launch the app. That wouldn't prevent the same Service Worker from being used in the browser if the user navigated to https://evernote.com/Home.action.

If the home-screen-thing has a different storage & SW, the system can detect which origins the user has icons for and remove storage & SW without the manifest.

Not necessarily, there could be multiple apps installed from the same origin. I don't think the OS would necessarily know which Service Workers to unregister.

How would you tell the difference between a normal SW install, and one triggered from add-to-homescreen?

That's a fair point. I guess the developer would have to specify a separate Service Worker in the manifest as an installation script, which then in turn registers other Service Workers which would also be registered in the browser.

I guess the question is really whether there's enough value in:

  • Being able to specify a Service Worker in the manifest to be registered at install time before an application context is created, vs. relying on the Service Worker being registered before installation via a browsing context and surviving the transition to an application context, otherwise risk that the app might not work offline etc. the first time it is launched.
  • An install event which is fired at install time.
  • Whether having a Service Worker which is only registered when the app is installed, or having a different Service Worker registered when the app is installed, is a valid design choice.

As you say, a general install event could be implemented separately if considered useful, but might just re-invent Service Workers.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jan 16, 2015

Member

That's a fair point. I guess the developer would have to specify a separate Service Worker in the manifest as an installation script, which then in turn registers other Service Workers which would also be registered in the browser.

This is exactly what I don't want to ever see happen - and what worries me most about SW in the manifest. IMO, declarative solutions that allow for this level of discrimination ends up harming users most of all, because it (unwittingly) ends up only making features available to a subset of user agents - even if the developer wants to do the right thing, the manifest simply can't help them there. This is why the SW API is a better solution for all this.

The consequences of adding SWs to manifest being:

  • the app will expect install in order to work properly. Ignoring legacy and no-supporting UAs with no ability to fallback (unlike the imperative SW API, which forces you into treating SW as a progressive enhancement).
  • The apps just start nagging users to "install my app! do it!! DO IT!!! DO!... IT!..." in order to get the "full experience". This is bad.
  • It increases the risk of: "this works best in Browsers X and Y!" which support service workers.

In the interest of not replicating features, and given the problems already outlined, I'm going to close this feature request. I think we should revisit this in a year or so once we've seen how people are using SWs in the wild. If search engines start working as marketplaces, then we can again revisit this.

Member

marcoscaceres commented Jan 16, 2015

That's a fair point. I guess the developer would have to specify a separate Service Worker in the manifest as an installation script, which then in turn registers other Service Workers which would also be registered in the browser.

This is exactly what I don't want to ever see happen - and what worries me most about SW in the manifest. IMO, declarative solutions that allow for this level of discrimination ends up harming users most of all, because it (unwittingly) ends up only making features available to a subset of user agents - even if the developer wants to do the right thing, the manifest simply can't help them there. This is why the SW API is a better solution for all this.

The consequences of adding SWs to manifest being:

  • the app will expect install in order to work properly. Ignoring legacy and no-supporting UAs with no ability to fallback (unlike the imperative SW API, which forces you into treating SW as a progressive enhancement).
  • The apps just start nagging users to "install my app! do it!! DO IT!!! DO!... IT!..." in order to get the "full experience". This is bad.
  • It increases the risk of: "this works best in Browsers X and Y!" which support service workers.

In the interest of not replicating features, and given the problems already outlined, I'm going to close this feature request. I think we should revisit this in a year or so once we've seen how people are using SWs in the wild. If search engines start working as marketplaces, then we can again revisit this.

@slightlyoff

This comment has been minimized.

Show comment
Hide comment
@slightlyoff

slightlyoff Jan 28, 2015

I can't agree with most of @benfrancis's logic; evernote has created their own tortured world and they have lots of ways out -- they don't need the manifest to do it for them.

That said, I'm OK with punting on integration for now and leaning on the implicit connection between the document being loaded from start_url and a controlling SW.

UAs will have to implement a rule that says that if there isn't a SW for start_url, then it isn't really an app. That doesn't feel particularly onerous, though, and shouldn't bite too many site authors. They will clearly have meant for these things to overlap.

It further allows us to define a different semantic for a manifest-specified SW later (should it be needed).

I can't agree with most of @benfrancis's logic; evernote has created their own tortured world and they have lots of ways out -- they don't need the manifest to do it for them.

That said, I'm OK with punting on integration for now and leaning on the implicit connection between the document being loaded from start_url and a controlling SW.

UAs will have to implement a rule that says that if there isn't a SW for start_url, then it isn't really an app. That doesn't feel particularly onerous, though, and shouldn't bite too many site authors. They will clearly have meant for these things to overlap.

It further allows us to define a different semantic for a manifest-specified SW later (should it be needed).

@skddc

This comment has been minimized.

Show comment
Hide comment
@skddc

skddc Jan 28, 2015

Contributor

UAs will have to implement a rule that says that if there isn't a SW for start_url, then it isn't really an app.

Serious apps that exist today don't use SW, so that logic would exclude basically every app that doesn't switch for some reason -- maybe no other reason than satisfying this arbitrary requirement. It might not be very popular, but AppCache exists and is being used today.

Contributor

skddc commented Jan 28, 2015

UAs will have to implement a rule that says that if there isn't a SW for start_url, then it isn't really an app.

Serious apps that exist today don't use SW, so that logic would exclude basically every app that doesn't switch for some reason -- maybe no other reason than satisfying this arbitrary requirement. It might not be very popular, but AppCache exists and is being used today.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jan 28, 2015

Contributor

This seems like an area where UAs will compete. @slightlyoff feels strongly that a "real app" must have a SW, and his perspective will presumably carry over into Chrome's product direction. Other vendors will likely be more lenient. Each will produce a different user experience, and we'll find out which makes users happier through experience.

Contributor

domenic commented Jan 28, 2015

This seems like an area where UAs will compete. @slightlyoff feels strongly that a "real app" must have a SW, and his perspective will presumably carry over into Chrome's product direction. Other vendors will likely be more lenient. Each will produce a different user experience, and we'll find out which makes users happier through experience.

@skddc

This comment has been minimized.

Show comment
Hide comment
@skddc

skddc Jan 28, 2015

Contributor

searching the Internets for pictures of unicorns and rainbows

I know how much some people like SW. However, I don't see how "real apps use SW" is a reasonable opinion, that can't be altered in the slightest by app developers and app hosters giving feedback.

You probably wouldn't go ahead and require IndexedDB to be used over localStorage for considering an app to be "a real app". Yet, that's basically what this does. Depending on the use case, either one makes sense and neither visibly alters the end user experience of storing data offline, if used correctly (given no performance issues with chosen spec for use case).

Anyway, looking forward to seeing this being implemented in any way, shape or form, and collecting/reporting experience with whatever our vendor overlords decide to implement. :)

Contributor

skddc commented Jan 28, 2015

searching the Internets for pictures of unicorns and rainbows

I know how much some people like SW. However, I don't see how "real apps use SW" is a reasonable opinion, that can't be altered in the slightest by app developers and app hosters giving feedback.

You probably wouldn't go ahead and require IndexedDB to be used over localStorage for considering an app to be "a real app". Yet, that's basically what this does. Depending on the use case, either one makes sense and neither visibly alters the end user experience of storing data offline, if used correctly (given no performance issues with chosen spec for use case).

Anyway, looking forward to seeing this being implemented in any way, shape or form, and collecting/reporting experience with whatever our vendor overlords decide to implement. :)

@adrianhopebailie

This comment has been minimized.

Show comment
Hide comment
@adrianhopebailie

adrianhopebailie Sep 12, 2016

Unfortunately that's not how the web's built today. Take github pages for example - one origin, many sites.

I don't follow this. Github uses subdomains so each Github site is a unique origin.

So adding a payment app will require a permission prompt?

Yes, that's certainly my assumption.

I'm trying to get to the root of why using manifest is so desirable here.

Re-use of the manifest data model. An "extensible Web" approach to Web architecture.

The issue is that the concept of an application manifest is broad and so is the definition of a Web application. The idea of providing meta-data about your application has a many use cases.

This spec has taken the idea of a standard way of defining app meta data and put it in a spec that is very difficult to use unless your definition of an app, including how it is installed is the same as the editors'. This is a website manifest, not an app manifest.

This data model, a nice generic one that SHOULD be reusable and extensible, is tightly coupled to an installation process that is not.

It's just one of many examples where there are major inconsistencies between W3C specs on simple architectural concepts like what defines an app boundary. Pity the poor fool who wants to become a Web developer 😢

Unfortunately that's not how the web's built today. Take github pages for example - one origin, many sites.

I don't follow this. Github uses subdomains so each Github site is a unique origin.

So adding a payment app will require a permission prompt?

Yes, that's certainly my assumption.

I'm trying to get to the root of why using manifest is so desirable here.

Re-use of the manifest data model. An "extensible Web" approach to Web architecture.

The issue is that the concept of an application manifest is broad and so is the definition of a Web application. The idea of providing meta-data about your application has a many use cases.

This spec has taken the idea of a standard way of defining app meta data and put it in a spec that is very difficult to use unless your definition of an app, including how it is installed is the same as the editors'. This is a website manifest, not an app manifest.

This data model, a nice generic one that SHOULD be reusable and extensible, is tightly coupled to an installation process that is not.

It's just one of many examples where there are major inconsistencies between W3C specs on simple architectural concepts like what defines an app boundary. Pity the poor fool who wants to become a Web developer 😢

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Sep 12, 2016

@adrianhopebailie

I don't follow this. Github uses subdomains so each Github site is a unique origin.

Unfortunately not:

Re-use of the manifest data model. An "extensible Web" approach to Web architecture.

The extensible web manifesto relates to providing low-level APIs, I'm not sure how the manifest fits into this comparison. The manifest is a pretty high-level API compared to the service worker.

This data model, a nice generic one that SHOULD be reusable and extensible, is tightly coupled to an installation process that is not. …It's just one of many examples where there are major inconsistencies between W3C specs on simple architectural concepts like what defines an app boundary. Pity the poor fool who wants to become a Web developer

Let's keep calm about this. An app vs site is almost impossible to define, and I don't think it's something the w3c should define.

The model for long-lived "registrations", that can change over time via a defined lifecycle, is the service worker. It's already being used for this purpose by push, sync, foreign fetch, and soon background fetch. So if the payments WG want to split it down the middle and straddle the SW and manifest for this state storage, then that needs to be justified.

If the reason is because of some common fields (that may or may not be the same as what the site already has), we can probably reuse the algorithms. Eg many specs want "responsive image" like behaviour whatwg/notifications#76.

@adrianhopebailie

I don't follow this. Github uses subdomains so each Github site is a unique origin.

Unfortunately not:

Re-use of the manifest data model. An "extensible Web" approach to Web architecture.

The extensible web manifesto relates to providing low-level APIs, I'm not sure how the manifest fits into this comparison. The manifest is a pretty high-level API compared to the service worker.

This data model, a nice generic one that SHOULD be reusable and extensible, is tightly coupled to an installation process that is not. …It's just one of many examples where there are major inconsistencies between W3C specs on simple architectural concepts like what defines an app boundary. Pity the poor fool who wants to become a Web developer

Let's keep calm about this. An app vs site is almost impossible to define, and I don't think it's something the w3c should define.

The model for long-lived "registrations", that can change over time via a defined lifecycle, is the service worker. It's already being used for this purpose by push, sync, foreign fetch, and soon background fetch. So if the payments WG want to split it down the middle and straddle the SW and manifest for this state storage, then that needs to be justified.

If the reason is because of some common fields (that may or may not be the same as what the site already has), we can probably reuse the algorithms. Eg many specs want "responsive image" like behaviour whatwg/notifications#76.

@adrianhopebailie

This comment has been minimized.

Show comment
Hide comment
@adrianhopebailie

adrianhopebailie Sep 12, 2016

There are two ways to use GitHub pages, using a gh-pages branch which allows a per repo website under a single team/user origin or using a single repo per team/user that is the site at the root.

This way GitHub can serve a separate app for each user/team on a different origin. i.e. User's have the choice.

I suspect that the developers at Github thought about this and that's they don't just render each team/user site at www.github.io/user?

The extensible web manifesto relates to providing low-level APIs, I'm not sure how the manifest fits into this comparison. The manifest is a pretty high-level API compared to the service worker.

This is not a comparison of manifest and service worker. Extensibility as a concept is about re-use of composable parts. The manifesto may focus on low-level APIs but the same applies to common data models (a key piece of most APIs). Appmanifest defines a data model that could be re-used if the current designed didn't prevent that.

An app vs site is almost impossible to define, and I don't think it's something the w3c should define.

If the W3C can't define the difference between an app and a site but publishes a spec called "appmanifest" then who can define the difference?

The Web developer's toolkit is constantly growing and yet for some reason the tools are getting more complicated and less consistent which I find frustrating and a bit ridiculous given that there is a group at W3C responsible for technical architecture whose mandate is looking across all of the work and ensuring consistency, interoperability and good architecture.

The ability to define application boundaries for security, execution context etc is basic software architecture but it seems like there are no clear answers on how to define these things.

The best response I've had on this was from @mikewest who said the only true app boundary on the Web is an origin so then I wonder why we'd not enforce that for anything new, accepting that the legacy that is out there must deal with ambiguity.

Payment apps are an entirely new thing. We can define them how we want to and perhaps we should say that only one is allowed per origin?

So if the payments WG want to split it down the middle and straddle the SW and manifest for this state storage, then that needs to be justified.

This is not about state storage, it's about decoupling the data model (manifest) from the life-cycle management so that we end up with an extensible, re-usable design.

If we can acheive that, then when we define a registration behaviour for payment apps that matches algorithms from app manifest, then re-use isn't just "copy and paste" it's actual re-use.

There are two ways to use GitHub pages, using a gh-pages branch which allows a per repo website under a single team/user origin or using a single repo per team/user that is the site at the root.

This way GitHub can serve a separate app for each user/team on a different origin. i.e. User's have the choice.

I suspect that the developers at Github thought about this and that's they don't just render each team/user site at www.github.io/user?

The extensible web manifesto relates to providing low-level APIs, I'm not sure how the manifest fits into this comparison. The manifest is a pretty high-level API compared to the service worker.

This is not a comparison of manifest and service worker. Extensibility as a concept is about re-use of composable parts. The manifesto may focus on low-level APIs but the same applies to common data models (a key piece of most APIs). Appmanifest defines a data model that could be re-used if the current designed didn't prevent that.

An app vs site is almost impossible to define, and I don't think it's something the w3c should define.

If the W3C can't define the difference between an app and a site but publishes a spec called "appmanifest" then who can define the difference?

The Web developer's toolkit is constantly growing and yet for some reason the tools are getting more complicated and less consistent which I find frustrating and a bit ridiculous given that there is a group at W3C responsible for technical architecture whose mandate is looking across all of the work and ensuring consistency, interoperability and good architecture.

The ability to define application boundaries for security, execution context etc is basic software architecture but it seems like there are no clear answers on how to define these things.

The best response I've had on this was from @mikewest who said the only true app boundary on the Web is an origin so then I wonder why we'd not enforce that for anything new, accepting that the legacy that is out there must deal with ambiguity.

Payment apps are an entirely new thing. We can define them how we want to and perhaps we should say that only one is allowed per origin?

So if the payments WG want to split it down the middle and straddle the SW and manifest for this state storage, then that needs to be justified.

This is not about state storage, it's about decoupling the data model (manifest) from the life-cycle management so that we end up with an extensible, re-usable design.

If we can acheive that, then when we define a registration behaviour for payment apps that matches algorithms from app manifest, then re-use isn't just "copy and paste" it's actual re-use.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Sep 12, 2016

In my last comment I proposed reusing the algorithms without having to split storage. This would done without having a manifest.

If you're deciding to only allow one payment app per origin, you're outside the service worker lifecycle, and I wish you good luck, but it's a mistake.

I don't think app vs site needs to be defined to make this all work.

In my last comment I proposed reusing the algorithms without having to split storage. This would done without having a manifest.

If you're deciding to only allow one payment app per origin, you're outside the service worker lifecycle, and I wish you good luck, but it's a mistake.

I don't think app vs site needs to be defined to make this all work.

@adrianhopebailie

This comment has been minimized.

Show comment
Hide comment
@adrianhopebailie

adrianhopebailie Sep 12, 2016

I don't think app vs site needs to be defined to make this all work.

I think we have strayed way off track here. My original proposal was that payment apps could be a use case for motivating that app manifests be used to provide meta-data when registering a ServiceWorker.

I still think there is value in re-using the data model from appmanifest to describe the meta-data about a payment app (icon, labels etc) but we can't use the appmanifest spec directly because it couples the use of the manifest data model tightly to it's own installation algorithms.

This is a pity given that in most cases a payment app is likely to be far closer to the metaphor of an app as understood by most people than anything currently using app manifest.

I don't think app vs site needs to be defined to make this all work.

I think we have strayed way off track here. My original proposal was that payment apps could be a use case for motivating that app manifests be used to provide meta-data when registering a ServiceWorker.

I still think there is value in re-using the data model from appmanifest to describe the meta-data about a payment app (icon, labels etc) but we can't use the appmanifest spec directly because it couples the use of the manifest data model tightly to it's own installation algorithms.

This is a pity given that in most cases a payment app is likely to be far closer to the metaphor of an app as understood by most people than anything currently using app manifest.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Sep 13, 2016

Many other specs need a model for processing icons. We should abstract that, and it can be used in multiple places.

Are we agreed that payment app settings can be provided to an API in the service worker without requiring a separate JSON resource (or resources)? If so, we should leave this thread.

Many other specs need a model for processing icons. We should abstract that, and it can be used in multiple places.

Are we agreed that payment app settings can be provided to an API in the service worker without requiring a separate JSON resource (or resources)? If so, we should leave this thread.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Sep 13, 2016

Member

My original proposal was that payment apps could be a use case for motivating that app manifests be used to provide meta-data when registering a ServiceWorker.

Why? Why go through the manifest processing dance? why go to the network for a manifest file at all? That makes little sense to me. One is free to compose the payment details from the payment application from the manifest (e.g., if you want to pull resources or the manifest out of cache storage), but relying on the manifest and processing model seems wrong.

I still think there is value in re-using the data model from appmanifest to describe the meta-data about a payment app (icon, labels etc) but we can't use the appmanifest spec directly because it couples the use of the manifest data model tightly to it's own installation algorithms.

This is by design. It's serving a very particular and limited purpose to do with installation and OS integration.

This is a pity given that in most cases a payment app is likely to be far closer to the metaphor of an app as understood by most people than anything currently using app manifest.

I'm sorry, but that's a bogus claim to make. Firstly, 99% of the time, payments are going to be going through the OS preferred payment provider (i.e., Apple Pay or Android Pay).

The (web) applications that hook into the payment providers are the ones that provide value - by affording the actual acquisition of goods and services: the payment providers are appendages, much like PayPal is for eBay, etc. If payment providers make nice (web) apps, then they will get installed too. But no one shouldn't have to "install" a payment provider's app - only have enough details for a monetary transaction to take place.

Member

marcoscaceres commented Sep 13, 2016

My original proposal was that payment apps could be a use case for motivating that app manifests be used to provide meta-data when registering a ServiceWorker.

Why? Why go through the manifest processing dance? why go to the network for a manifest file at all? That makes little sense to me. One is free to compose the payment details from the payment application from the manifest (e.g., if you want to pull resources or the manifest out of cache storage), but relying on the manifest and processing model seems wrong.

I still think there is value in re-using the data model from appmanifest to describe the meta-data about a payment app (icon, labels etc) but we can't use the appmanifest spec directly because it couples the use of the manifest data model tightly to it's own installation algorithms.

This is by design. It's serving a very particular and limited purpose to do with installation and OS integration.

This is a pity given that in most cases a payment app is likely to be far closer to the metaphor of an app as understood by most people than anything currently using app manifest.

I'm sorry, but that's a bogus claim to make. Firstly, 99% of the time, payments are going to be going through the OS preferred payment provider (i.e., Apple Pay or Android Pay).

The (web) applications that hook into the payment providers are the ones that provide value - by affording the actual acquisition of goods and services: the payment providers are appendages, much like PayPal is for eBay, etc. If payment providers make nice (web) apps, then they will get installed too. But no one shouldn't have to "install" a payment provider's app - only have enough details for a monetary transaction to take place.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Sep 13, 2016

Member

Many other specs need a model for processing icons. We should abstract that, and it can be used in multiple places.

Exactly. The manifest spec leverages a lot from HTML already.

Are we agreed that payment app settings can be provided to an API in the service worker without requiring a separate JSON resource (or resources)? If so, we should leave this thread.

I hope so. That feels like a much better fit to me.

Member

marcoscaceres commented Sep 13, 2016

Many other specs need a model for processing icons. We should abstract that, and it can be used in multiple places.

Exactly. The manifest spec leverages a lot from HTML already.

Are we agreed that payment app settings can be provided to an API in the service worker without requiring a separate JSON resource (or resources)? If so, we should leave this thread.

I hope so. That feels like a much better fit to me.

@adrianhopebailie

This comment has been minimized.

Show comment
Hide comment
@adrianhopebailie

adrianhopebailie Sep 13, 2016

relying on the manifest and processing model seems wrong.

If you assume that the manifest data model is only available in the form of a JSON object in a file, sure.

I'm sorry, but that's a bogus claim to make. Firstly, 99% of the time, payments are going to be going through the OS preferred payment provider (i.e., Apple Pay or Android Pay).

The (web) applications that hook into the payment providers are the ones that provide value - by affording the actual acquisition of goods and services: the payment providers are appendages, much like PayPal is for eBay, etc. If payment providers make nice (web) apps, then they will get installed too. But no one shouldn't have to "install" a payment provider's app - only have enough details for a monetary transaction to take place.

I'm sorry but I don't think you understand the model that is being proposed for payment apps and why they will be installed or who would publish them. Your perspective is very card-centric and assumes that payment apps will just be glorified card number providers or built into the browser/OS.

On the one hand you are saying that the tight coupling of the data-model to the installation process is "by design" and on the other hand abstracting parts of this spec out for re-use is a good idea. So which is it?

All I proposed was that by doing the latter, aspects of this spec would be useful in new use cases such as payment apps. I.e. Payment apps is a use case where the appmanifest data model could be re-used in registering a ServiceWorker that is a payment app and therefor needs a label, icon etc.

adrianhopebailie commented Sep 13, 2016

relying on the manifest and processing model seems wrong.

If you assume that the manifest data model is only available in the form of a JSON object in a file, sure.

I'm sorry, but that's a bogus claim to make. Firstly, 99% of the time, payments are going to be going through the OS preferred payment provider (i.e., Apple Pay or Android Pay).

The (web) applications that hook into the payment providers are the ones that provide value - by affording the actual acquisition of goods and services: the payment providers are appendages, much like PayPal is for eBay, etc. If payment providers make nice (web) apps, then they will get installed too. But no one shouldn't have to "install" a payment provider's app - only have enough details for a monetary transaction to take place.

I'm sorry but I don't think you understand the model that is being proposed for payment apps and why they will be installed or who would publish them. Your perspective is very card-centric and assumes that payment apps will just be glorified card number providers or built into the browser/OS.

On the one hand you are saying that the tight coupling of the data-model to the installation process is "by design" and on the other hand abstracting parts of this spec out for re-use is a good idea. So which is it?

All I proposed was that by doing the latter, aspects of this spec would be useful in new use cases such as payment apps. I.e. Payment apps is a use case where the appmanifest data model could be re-used in registering a ServiceWorker that is a payment app and therefor needs a label, icon etc.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Sep 13, 2016

Shall we pick this up at TPAC? There's a bit of a sour air to the discussion that would probably be cleared up face-to-face.

Shall we pick this up at TPAC? There's a bit of a sour air to the discussion that would probably be cleared up face-to-face.

@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Sep 13, 2016

Collaborator

Yes, good idea :-) Then I can also see if I can understand it all. Marcos unfortunately won't be around.

Collaborator

kenchris commented Sep 13, 2016

Yes, good idea :-) Then I can also see if I can understand it all. Marcos unfortunately won't be around.

@RobDolinMS

This comment has been minimized.

Show comment
Hide comment
@RobDolinMS

RobDolinMS Sep 13, 2016

Collaborator

@kenchris @jakearchibald @marcoscaceres @adrianhopebailie I won't be at TPAC but am supportive of Service Worker being included in the Web App Manifest.

Two use cases of Service Workers mentioned in an earlier comment:

  • New Device / Back-up and Restore - When migrating to a new device, a user may "back-up" the list of apps from their old device and then "restore" their apps on the new device.
  • Install now, first run later - Similar to above. I personally hit this over the weekend while traveling with my two-year-old child. I browsed a list of apps/games for age < 5 and installed a few of these. Then, when on the 4.5 hour cross-country flight (without Wi-Fi), I tried to run these apps.
Collaborator

RobDolinMS commented Sep 13, 2016

@kenchris @jakearchibald @marcoscaceres @adrianhopebailie I won't be at TPAC but am supportive of Service Worker being included in the Web App Manifest.

Two use cases of Service Workers mentioned in an earlier comment:

  • New Device / Back-up and Restore - When migrating to a new device, a user may "back-up" the list of apps from their old device and then "restore" their apps on the new device.
  • Install now, first run later - Similar to above. I personally hit this over the weekend while traveling with my two-year-old child. I browsed a list of apps/games for age < 5 and installed a few of these. Then, when on the 4.5 hour cross-country flight (without Wi-Fi), I tried to run these apps.
@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Sep 14, 2016

Member

The use cases are very compelling - and would like to explore how they would work in practice. Open questions:

  • should we allow multiple service work registrations? Or just a single one?
  • what happens when registration fails?
Member

marcoscaceres commented Sep 14, 2016

The use cases are very compelling - and would like to explore how they would work in practice. Open questions:

  • should we allow multiple service work registrations? Or just a single one?
  • what happens when registration fails?
@adrianhopebailie

This comment has been minimized.

Show comment
Hide comment
@adrianhopebailie

adrianhopebailie Sep 14, 2016

Yes, good idea. Apologies if my frustrations with understanding the different boundaries between cookies, apps, sw's etc turned things sour. I have a long standing peev with the number of moving parts in W3C specs that don't seem to inter-operate well unless you have some of the tribal knowledge that helps you understand the nuances.

We had a payment app task force call today and this was discussed so I think I can provide some more clarity:

  • Payment apps will be ServiceWorkers (the bleeding edge spec from @adamroach provides more detail: https://adamroach.github.io/webpayments-payment-apps-api/#payment-app-manifest)
  • The current proposal is to define our own data model that would be input into the ServiceWorker registration process to provide meta-data about the app. As you can see from some of the issue markers we need to deal with many of the same issues that appmanifest has already dealt with like "What is an icon, how do we have multiple icons of different sizes etc".
  • A case has been made for putting this data into a file so it can be re-used outside the scope of the ServiceWorker. See: w3c/webpayments-payment-apps-api#33 (comment)
  • Another reason for having this meta-data available prior to executing the SW registration is that the browser needs some of this meta-data in providing UI to the user to, for example, prompt them to install a payment app they don't have but which is known to support a specific payment method.

So payment apps would benefit from the data model and algorithms defined in app manifest for things like specifying icons but we don't want to buy into the life-cycle management of appmanifest we want to use SW for that.

What could change to make this work "better":

  1. Appmanifest defines it's data model using WebIDL and separate algorithms for parsing the JSON and processing the data. This AppManifest could probably replace the PaymentAppManifest or just be extended by it?
  2. Appmanifest describes it's current lifecycle management stuff in terms of it's specific use case and in a way that explicitly says "use this data model in other ways if you want to but this is how we use manifest files via link tags and this is what to expect if that's what you do"
  3. Appmanifest includes the possibility of defining a SW instead of a start_url and the "installation" of the app follows the SW lifecycle where the WebIDL defined JS object version of the manifest data is available to the SW during the registration process. This mirros the pattern in other platforms of having a common code base that can be executed differently based on context and runtime parameters (ENV variables, config files etc)

With the following changes a payment app would simply be a specialization of SW that uses appmanifests to define it's meta-data. I may be missing some key considerations here so invite a conversation to clarify at TPAC.

adrianhopebailie commented Sep 14, 2016

Yes, good idea. Apologies if my frustrations with understanding the different boundaries between cookies, apps, sw's etc turned things sour. I have a long standing peev with the number of moving parts in W3C specs that don't seem to inter-operate well unless you have some of the tribal knowledge that helps you understand the nuances.

We had a payment app task force call today and this was discussed so I think I can provide some more clarity:

  • Payment apps will be ServiceWorkers (the bleeding edge spec from @adamroach provides more detail: https://adamroach.github.io/webpayments-payment-apps-api/#payment-app-manifest)
  • The current proposal is to define our own data model that would be input into the ServiceWorker registration process to provide meta-data about the app. As you can see from some of the issue markers we need to deal with many of the same issues that appmanifest has already dealt with like "What is an icon, how do we have multiple icons of different sizes etc".
  • A case has been made for putting this data into a file so it can be re-used outside the scope of the ServiceWorker. See: w3c/webpayments-payment-apps-api#33 (comment)
  • Another reason for having this meta-data available prior to executing the SW registration is that the browser needs some of this meta-data in providing UI to the user to, for example, prompt them to install a payment app they don't have but which is known to support a specific payment method.

So payment apps would benefit from the data model and algorithms defined in app manifest for things like specifying icons but we don't want to buy into the life-cycle management of appmanifest we want to use SW for that.

What could change to make this work "better":

  1. Appmanifest defines it's data model using WebIDL and separate algorithms for parsing the JSON and processing the data. This AppManifest could probably replace the PaymentAppManifest or just be extended by it?
  2. Appmanifest describes it's current lifecycle management stuff in terms of it's specific use case and in a way that explicitly says "use this data model in other ways if you want to but this is how we use manifest files via link tags and this is what to expect if that's what you do"
  3. Appmanifest includes the possibility of defining a SW instead of a start_url and the "installation" of the app follows the SW lifecycle where the WebIDL defined JS object version of the manifest data is available to the SW during the registration process. This mirros the pattern in other platforms of having a common code base that can be executed differently based on context and runtime parameters (ENV variables, config files etc)

With the following changes a payment app would simply be a specialization of SW that uses appmanifests to define it's meta-data. I may be missing some key considerations here so invite a conversation to clarify at TPAC.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Sep 16, 2016

Member

Yes, good idea. Apologies if my frustrations with understanding the different boundaries between cookies, apps, sw's etc turned things sour. I have a long standing peev with the number of moving parts in W3C specs that don't seem to inter-operate well unless you have some of the tribal knowledge that helps you understand the nuances.

Welcome to the club! :)

So payment apps would benefit from the data model and algorithms defined in app manifest for things like specifying icons but we don't want to buy into the life-cycle management of appmanifest we want to use SW for that.

Re: icons, we might be able to push that stuff down the stack to HTML. It's where "responsive images" are defined. The manifest spec leverages HTML and fetch where it can, because we want both the security assurances and the consistent behavior.

Another spec dealing with icons is Notifications - so it also provides a good place to look (though it currently doesn't do responsive images for icons, AFAICT).

  1. Appmanifest defines it's data model using WebIDL and separate algorithms for parsing the JSON and processing the data. This AppManifest could probably replace the PaymentAppManifest or just be extended by it?

Need to do this regardless. I've had similar requests internally. However, we still need to go through the processing step to clean up the manifest's data to get something that can be fed to the IDL machinery.

  1. Appmanifest describes it's current lifecycle management stuff in terms of it's specific use case and in a way that explicitly says "use this data model in other ways if you want to but this is how we use manifest files via link tags and this is what to expect if that's what you do"

Yep?

  1. Appmanifest includes the possibility of defining a SW instead of a start_url

That doesn't make sense to me. But it could define an SW in addition to the start_url.

and the "installation" of the app follows the SW lifecycle where the WebIDL defined JS object version of the manifest data is available to the SW during the registration process.

If installation is triggered from the manifest, then sure. But why can't you just fetch it? Why do you need the clean object?

This mirros the pattern in other platforms of having a common code base that can be executed differently based on context and runtime parameters (ENV variables, config files etc)

Let's not jump the shark. Remember you can still get the manifest simply by:

addEventListener("install", (ev)=>{
    ev.waitUntil(async function(){
        const json = await fetch("manifest.json").then(r => r.json());
       // ok now what?
    })
}); 

The question is, what do you then want to do with the manifest data?

Member

marcoscaceres commented Sep 16, 2016

Yes, good idea. Apologies if my frustrations with understanding the different boundaries between cookies, apps, sw's etc turned things sour. I have a long standing peev with the number of moving parts in W3C specs that don't seem to inter-operate well unless you have some of the tribal knowledge that helps you understand the nuances.

Welcome to the club! :)

So payment apps would benefit from the data model and algorithms defined in app manifest for things like specifying icons but we don't want to buy into the life-cycle management of appmanifest we want to use SW for that.

Re: icons, we might be able to push that stuff down the stack to HTML. It's where "responsive images" are defined. The manifest spec leverages HTML and fetch where it can, because we want both the security assurances and the consistent behavior.

Another spec dealing with icons is Notifications - so it also provides a good place to look (though it currently doesn't do responsive images for icons, AFAICT).

  1. Appmanifest defines it's data model using WebIDL and separate algorithms for parsing the JSON and processing the data. This AppManifest could probably replace the PaymentAppManifest or just be extended by it?

Need to do this regardless. I've had similar requests internally. However, we still need to go through the processing step to clean up the manifest's data to get something that can be fed to the IDL machinery.

  1. Appmanifest describes it's current lifecycle management stuff in terms of it's specific use case and in a way that explicitly says "use this data model in other ways if you want to but this is how we use manifest files via link tags and this is what to expect if that's what you do"

Yep?

  1. Appmanifest includes the possibility of defining a SW instead of a start_url

That doesn't make sense to me. But it could define an SW in addition to the start_url.

and the "installation" of the app follows the SW lifecycle where the WebIDL defined JS object version of the manifest data is available to the SW during the registration process.

If installation is triggered from the manifest, then sure. But why can't you just fetch it? Why do you need the clean object?

This mirros the pattern in other platforms of having a common code base that can be executed differently based on context and runtime parameters (ENV variables, config files etc)

Let's not jump the shark. Remember you can still get the manifest simply by:

addEventListener("install", (ev)=>{
    ev.waitUntil(async function(){
        const json = await fetch("manifest.json").then(r => r.json());
       // ok now what?
    })
}); 

The question is, what do you then want to do with the manifest data?

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Sep 16, 2016

Member

(updated code above, added await and comment)

Member

marcoscaceres commented Sep 16, 2016

(updated code above, added await and comment)

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Sep 16, 2016

I think the payments stuff is a bit of a distraction here, because I still think their proposed reliance on manifest is a step against the extensible web, and @marcoscaceres example above shows that developers could choose to use JSON (or YAML, or whatever) really easily.

That aside, I'm open to service worker being referenced in the manifest. @RobDolinMS:

New Device / Back-up and Restore - When migrating to a new device, a user may "back-up" the list of apps from their old device and then "restore" their apps on the new device.

The service worker scope & script URL could just be backed up along with the app here right?

Install now, first run later - Similar to above. I personally hit this over the weekend while traveling with my two-year-old child. I browsed a list of apps/games for age < 5 and installed a few of these. Then, when on the 4.5 hour cross-country flight (without Wi-Fi), I tried to run these apps.

I agree this requires a declarative service worker registration, but we already have <link rel="serviceworker">, is this enough?

I think the payments stuff is a bit of a distraction here, because I still think their proposed reliance on manifest is a step against the extensible web, and @marcoscaceres example above shows that developers could choose to use JSON (or YAML, or whatever) really easily.

That aside, I'm open to service worker being referenced in the manifest. @RobDolinMS:

New Device / Back-up and Restore - When migrating to a new device, a user may "back-up" the list of apps from their old device and then "restore" their apps on the new device.

The service worker scope & script URL could just be backed up along with the app here right?

Install now, first run later - Similar to above. I personally hit this over the weekend while traveling with my two-year-old child. I browsed a list of apps/games for age < 5 and installed a few of these. Then, when on the 4.5 hour cross-country flight (without Wi-Fi), I tried to run these apps.

I agree this requires a declarative service worker registration, but we already have <link rel="serviceworker">, is this enough?

@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Sep 16, 2016

Collaborator

I would say yes, it works for <link and Link header, so why shouldn't it be enough for manifest?

How do we handle today if there is a Link header with SW, a tag and a JS registration?

Collaborator

kenchris commented Sep 16, 2016

I would say yes, it works for <link and Link header, so why shouldn't it be enough for manifest?

How do we handle today if there is a Link header with SW, a tag and a JS registration?

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Sep 16, 2016

How do we handle today if there is a Link header with SW, a tag and a JS registration?

If they have different scopes, you get three registrations. If they have the same scope and script URL, they coalesce. If they have different script URLs, last one wins.

How do we handle today if there is a Link header with SW, a tag and a JS registration?

If they have different scopes, you get three registrations. If they have the same scope and script URL, they coalesce. If they have different script URLs, last one wins.

@marcoscaceres marcoscaceres added P1 and removed P2 labels Sep 20, 2016

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Sep 20, 2016

Member

Ok, I'm convinced. Let's do this.

Member

marcoscaceres commented Sep 20, 2016

Ok, I'm convinced. Let's do this.

@benfrancis

This comment has been minimized.

Show comment
Hide comment
@benfrancis

benfrancis Sep 20, 2016

\o/

To be fair it is now nearly two years since you said:

Still probably about 1-2 year till SWs are stable.

\o/

To be fair it is now nearly two years since you said:

Still probably about 1-2 year till SWs are stable.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Sep 20, 2016

Member

On 20 Sep. 2016, at 11:39 pm, Ben Francis notifications@github.com wrote:

\o/

To be fair it is now nearly two years since you said:

Still probably about 1-2 year till SWs are stable.

Was I wrong? ;) well, maybe 50% wrong.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Member

marcoscaceres commented Sep 20, 2016

On 20 Sep. 2016, at 11:39 pm, Ben Francis notifications@github.com wrote:

\o/

To be fair it is now nearly two years since you said:

Still probably about 1-2 year till SWs are stable.

Was I wrong? ;) well, maybe 50% wrong.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@RobDolinMS

This comment has been minimized.

Show comment
Hide comment
@RobDolinMS

RobDolinMS Sep 20, 2016

Collaborator

@marcoscaceres wrote:

Ok, I'm convinced. Let's do this.

Woo hoo! /cc @seksenov

Collaborator

RobDolinMS commented Sep 20, 2016

@marcoscaceres wrote:

Ok, I'm convinced. Let's do this.

Woo hoo! /cc @seksenov

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Sep 21, 2016

Member

Relevant discussion in the SW repo:
w3c/ServiceWorker#979

    "service_workers": [{
        "src": "sw.js",
        "scope": "/foo",
         "options": {} 
    }
Member

marcoscaceres commented Sep 21, 2016

Relevant discussion in the SW repo:
w3c/ServiceWorker#979

    "service_workers": [{
        "src": "sw.js",
        "scope": "/foo",
         "options": {} 
    }
@RobDolinMS

This comment has been minimized.

Show comment
Hide comment
@RobDolinMS

RobDolinMS Oct 12, 2016

Collaborator

@marcoscaceres Would you like me (or a colleague) to take a stab at a PR for your proposal?

Collaborator

RobDolinMS commented Oct 12, 2016

@marcoscaceres Would you like me (or a colleague) to take a stab at a PR for your proposal?

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Oct 13, 2016

Member

@RobDolinMS, sure! That would be great! I'd suggest starting small tho, because integration with the service worker spec is potentially tricky (e.g., there might not be a client for the installation, etc.).

Member

marcoscaceres commented Oct 13, 2016

@RobDolinMS, sure! That would be great! I'd suggest starting small tho, because integration with the service worker spec is potentially tricky (e.g., there might not be a client for the installation, etc.).

@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Oct 20, 2016

Collaborator

Any update on this?

Collaborator

kenchris commented Oct 20, 2016

Any update on this?

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Oct 20, 2016

Member

On 20 Oct. 2016, at 10:38 pm, Kenneth Rohde Christiansen notifications@github.com wrote:

Any update on this?

After we finish BIP I'll get onto it, unless the MS folks beat me to it... or do you want to get it started?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Member

marcoscaceres commented Oct 20, 2016

On 20 Oct. 2016, at 10:38 pm, Kenneth Rohde Christiansen notifications@github.com wrote:

Any update on this?

After we finish BIP I'll get onto it, unless the MS folks beat me to it... or do you want to get it started?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Oct 20, 2016

Collaborator

I can do it

Collaborator

kenchris commented Oct 20, 2016

I can do it

@anssiko

This comment has been minimized.

Show comment
Hide comment
@anssiko

anssiko Jan 24, 2017

Collaborator

A fix landed in #507, closing this issue.

Opened #542 to track a related issue.

Collaborator

anssiko commented Jan 24, 2017

A fix landed in #507, closing this issue.

Opened #542 to track a related issue.

@anssiko anssiko closed this Jan 24, 2017

@nuxodin

This comment has been minimized.

Show comment
Hide comment
@nuxodin

nuxodin Aug 4, 2017

Maybe we should add a "type" member for "service_workers"

{ "type": "module" }

Will be needed once Browsers support serviceWorkers as js modules.
https://html.spec.whatwg.org/#module-worker-example

nuxodin commented Aug 4, 2017

Maybe we should add a "type" member for "service_workers"

{ "type": "module" }

Will be needed once Browsers support serviceWorkers as js modules.
https://html.spec.whatwg.org/#module-worker-example

@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Aug 4, 2017

Collaborator

@nuxodin can you open a separate issue for this?

Collaborator

kenchris commented Aug 4, 2017

@nuxodin can you open a separate issue for this?

@nuxodin

This comment has been minimized.

Show comment
Hide comment
@nuxodin

nuxodin Aug 4, 2017

done: #594

nuxodin commented Aug 4, 2017

done: #594

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment