Open jyasskin opened 9 years ago
We already thought a bit about Service Worker integration but postponed it for now. If it is required for the new Permissions API / UX, we will have a look at it again.
I don't think you have to use Service Workers to deal with this; they're just an option. We haven't yet figured out how to deal with this in Web Bluetooth either, so we'll try to imitate whatever this group comes up with.
Another possibility is to treat the read
event like a MessagePort
's message
event: messages can get queued in the port's message queue, but they don't cause message
events until the queue is enabled by the MessagePort.start()
call. Although that doesn't quite fit since two Documents might have read
handlers set up that could receive the same NDEF messages.
Yes, we originally wanted to avoid service workers - because it might not be where you want the application logic to live - like say you want to write to a tag. On the other hand, Service Workers makes a lot of sense for offline handling etc.
The question is basically how we would handle registration for events when the page is not available. In some ways this is similar to the earlier Web Intents and Web Activations (from moz).
openWindow was recently added to Service Workers for dealing with "page activation" from a notification, so if we go for Service Workers, it might be an option.
Having NFC handling live in two places (page and service worker) seems confusing though, and I am not sure the API will be very user friendly if we move all of it to the Service Worker.
Any API suggestion to how this could work are of course welcome!
Right now, it looks like the spec assumes that a single JS context will exist contiguously from when
watch()
is called to when the matching NDEF message shows up and fires theread
event. But the permission UI suggested in #63 would allow a page to callwatch()
and then be closed, and when the NDEF message shows up, the user can re-open the page to handle the message.One could handle this by firing the
read
event in the page's Service Worker, but then we'll need guidelines to help ensure that the user sees that something happened when they chose the site. Or there could be some facility to let a page have a "pending" NDEF message while it's starting, which is fired as soon as a matchingwatch()
is set up. We'll still probably need to address pages that fail to call the matchingwatch()
.