This seems like it could become a very common pattern for a variety of APIs that need to show UI for specific contexts. In fact, I would argue that there's a generalizable pattern here: 1. Website W triggers event E. 2. Previously installed ServiceWorkers that are listening for (and have permission to handle) E receive it (with an optional step where the browser mediates *which* ServiceWorker will receive it via user interaction or previously configured options). 3. ServiceWorker calls E.openClientWindow() and does something in the context of the event. 4. Profit ... or whatever. I agree that we want to keep in the spirit of the extensible Web. However, even though there may be some mechanism for doing this already in a ServiceWorker, it seems that it is insufficient to explicitly cover the above "contextual" use case. Furthermore, this use case is likely to come up in a variety of places in the future -- not just payments, (e.g. credentials, intents, web share, verifiable claims, etc). So whatever we do, it should be done in a way that can be reused by other (future) APIs so that everyone isn't repeating themselves. That would be in keeping with the extensible Web -- it's just that perhaps we actually do need something a bit different here. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webpayments-payment-apps-api/issues/97#issuecomment-274650698
Received on Monday, 23 January 2017 23:24:32 UTC