New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

service workers, protocol handlers #17

Open
zolkis opened this Issue Apr 28, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@zolkis
Contributor

zolkis commented Apr 28, 2015

Are service workers supported, or only visible web pages can handle NFC?

Web NFC implementations could have policies like:

  • if there is an open visible page that handles NFC (i.e. has requested an adapter), let it handle it
  • otherwise, if there is a single service worker running, let it handle it
  • otherwise, if there are multiple service workers, ... .

Certainly, at any point of time there should be max one page that can handle NFC (reads and writes alike).

Should we use protocol handlers? like:
navigator.registerProtocolHandler('web+nfc', 'http://myorigin.com?q=blabla', 'MyApp');

@flaki

This comment has been minimized.

Show comment
Hide comment
@flaki

flaki Apr 28, 2015

Service Workers are event-based background workers, which means most of the time there shouldn't be any service workers running unless they are servicing a request (be it for a page/navigation, or other background tasks like incoming notifications for push messages).

That said, once spun up, service workers remain running for some time solely for optimization purposes (there are ongoing talks for how long they should be kept alive by default, though - w3c/ServiceWorker#679).

There are two ways to overcome this: one is to have the events baked in to the platform and make service workers capable of receiving incoming NFC data (that would need working with SW spec authors I guess). Such an NFC event would then be able to spin up a worker if it wasn't running, just like other companion specs like Push Notifications do.

The other method is to place NFC comms into their own Web Worker. There is ongoing discussion to make Service Workers to be able to have their own workers/workers shared with pages they control. In this scenario, the NFC comms would be running in a worker thread and only interacting with the page or service workers through this one indirection.

flaki commented Apr 28, 2015

Service Workers are event-based background workers, which means most of the time there shouldn't be any service workers running unless they are servicing a request (be it for a page/navigation, or other background tasks like incoming notifications for push messages).

That said, once spun up, service workers remain running for some time solely for optimization purposes (there are ongoing talks for how long they should be kept alive by default, though - w3c/ServiceWorker#679).

There are two ways to overcome this: one is to have the events baked in to the platform and make service workers capable of receiving incoming NFC data (that would need working with SW spec authors I guess). Such an NFC event would then be able to spin up a worker if it wasn't running, just like other companion specs like Push Notifications do.

The other method is to place NFC comms into their own Web Worker. There is ongoing discussion to make Service Workers to be able to have their own workers/workers shared with pages they control. In this scenario, the NFC comms would be running in a worker thread and only interacting with the page or service workers through this one indirection.

@jyasskin

This comment has been minimized.

Show comment
Hide comment
@jyasskin

jyasskin Apr 28, 2015

The security model so far requires that the user see a web page while that web page is allowed to access the NFC radio. A service worker is, by definition, not visible, which implies that service workers can't access NFC.

jyasskin commented Apr 28, 2015

The security model so far requires that the user see a web page while that web page is allowed to access the NFC radio. A service worker is, by definition, not visible, which implies that service workers can't access NFC.

@zolkis

This comment has been minimized.

Show comment
Hide comment
@zolkis

zolkis Apr 28, 2015

Contributor

Which is also the model used by other NFC API's. The question is whether should we relax that when policies could be defined such that they could guarantee that at most one client can access NFC during a given touch "transaction".

Contributor

zolkis commented Apr 28, 2015

Which is also the model used by other NFC API's. The question is whether should we relax that when policies could be defined such that they could guarantee that at most one client can access NFC during a given touch "transaction".

@jyasskin

This comment has been minimized.

Show comment
Hide comment
@jyasskin

jyasskin Apr 28, 2015

The security model isn't based around "at most one" though: it's based around the user seeing the actor on their screen.

It's definitely worth designing the API so it extends naturally to service workers when we find a way to relax the security model, but I think it's premature to actually relax it yet.

jyasskin commented Apr 28, 2015

The security model isn't based around "at most one" though: it's based around the user seeing the actor on their screen.

It's definitely worth designing the API so it extends naturally to service workers when we find a way to relax the security model, but I think it's premature to actually relax it yet.

@zolkis

This comment has been minimized.

Show comment
Hide comment
@zolkis

zolkis Apr 28, 2015

Contributor

I assumed the outcome of applying policies would be to start or make visible the most relevant page that will handle NFC. I agree that this would be a v2 feature, I just wanted to make sure the API we are going to propose for v1 is forward compatible with this.

Contributor

zolkis commented Apr 28, 2015

I assumed the outcome of applying policies would be to start or make visible the most relevant page that will handle NFC. I agree that this would be a v2 feature, I just wanted to make sure the API we are going to propose for v1 is forward compatible with this.

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