- From: Shijun Sun <shijuns@microsoft.com>
- Date: Wed, 22 Oct 2014 21:17:28 +0000
- To: John Mellor <johnme@google.com>, Martin Thomson <martin.thomson@gmail.com>
- CC: public-webapps <public-webapps@w3.org>
On Wednesday, October 22, 2014 8:41 AM. John Mellor wrote: > See https://github.com/w3c/push-api/issues/74 and https://github.com/w3c/push-api/issues/82 for more details on when and why registrations might expire in a typical push service. Thanks John for the pointers! I have a few more questions. 1. When the PushRegistration expires, what are the options to notify the UA? Let's assume the case where the webapp is not active at the time. a. Should the webapp server push a special (and can be app-specific) message to the UA before the expiration? Since the webapp server manages the contract with the Push Server, it should have the best knowledge about the expiration policy. b. Or, should the Notification Server push a generic (but can be platform specific) expiration message? I don't expect the Push Server has the obligation, but would like to confirm here. I agree we should never poll. c. Or, if the PushRegistration should be renewed frequently and proactively to mitigate the issue? I don't see other options to inform the device and UA in order to trigger a pushregistrationchange event and then inform the webapp to renew or recreate the PushRegistration. 2. In case of either option 1.a or 1.b, assuming the expiration message is not dropped/lost (BTW, another flow path otherwise), I expect the SW should respond to the message and the UA doesn't have to fire the pushregistrationchange event. Is that a correct understanding? 3. Based on the current security model, in case the webapps (or maybe its SW) need to create a new PushRegistration, should the UA first get user permission (again)? All the Best, Shijun
Received on Wednesday, 22 October 2014 21:17:57 UTC