w3c / nfc

Early attempt at an NFC API for the Web - see https://github.com/w3c/web-nfc for current work
https://github.com/w3c/web-nfc
15 stars 21 forks source link

Deal with pages that are closed between watch() and the matching NDEF message #68

Open jyasskin opened 9 years ago

jyasskin commented 9 years ago

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 the read event. But the permission UI suggested in #63 would allow a page to call watch() 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 matching watch() is set up. We'll still probably need to address pages that fail to call the matching watch().

kenchris commented 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.

jyasskin commented 9 years ago

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.

kenchris commented 9 years ago

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!