Consider renaming pushregistrationlost about push-api HOT 16 CLOSED

I don't think pushregistrationlost is a very good name either (I came up with it). I'm not sure about pushregistrationrefresh though. Would pushregistrationexpired work for you? In response to an expiration the application can reregister.

from push-api.

Actually, the registration did not expire (would the word expired begged the question on how long a registration is valid then?)

from push-api.

What about pushregistrationchange? The word change is very generic (it could mean all of "lost", "invalidated", "expired") and would allow us to re-use the event if we introduce additional properties on the PushRegistration object that have to be changed, for example when cycling the encryption keys.

from push-api.

Is the implication here that the browser will detect a problem (by whatever means) with the registration and then generate a replacement automatically? pushregistrationchange implies to me that the browser is automatically regenerating a registration.

That could take a non-zero amount of time, so there are two events: the start of the outage, and point that the new registration information is available. Costin yesterday suggested that they had struggled with the same problem with GCM and concluded that the best solution was to surface the outage event, but let the application deal with a refresh. Since the application is likely to need to send new registration information to server anyway, it was more elegant to have something like:

getRegistration = whateverItsCalled.register()
      .then(registration => fetch(/* push registration.blah somewhere */)))
onregistrationgone = (e) => {
  e.waitUntil(getRegistration);
};

from push-api.

That is correct, current GCM would surface the event only and will not automatically perform a registration ID rotation/change behind the scene. We inform the application so that it can take the proper action to refresh registration as well as other action that may be specific to the application

from push-api.

I like pushregistrationchange most of the suggestions so far. It seems to fit well with existing event names [1] such as fullscreenchange, hashchange, and volumechange.
1: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/events/EventTypeNames.in

from push-api.

What is changing?

from push-api.

I think the GCM people can best describe the nature of the change. It sounds like something in the registration state has changed or is about to change.

from push-api.

I'll try to stop being obtuse :) The point I was trying to make before was that if you call it a change, then it had actually better be a change. But the problem with the change is that it involves two separate events, separated by time: the loss of the registration, and the subsequent replacement. That's not good, because you have a period during which the application can't receive messages and the application is unaware of this.

GCM solves this by avoiding the second event entirely, just surfacing the first. This makes it the responsibility of the application to refresh a registration, but that's actually trivial in practice: they just re-invoke the code that was used to create the initial registration.

I think that's a perfectly good design in principle. The problem with this API is that the initial registration seems to happen outside of the SW context. If you think that matters, I'd rather fix that.

from push-api.

@martinthomson: I'm not sure whether you actually have a concern.

The problem with this API is that the initial registration seems to happen outside of the SW context.

PushRegistrationManager is exposed on ServiceWorkerRegistration which can be acquired in both document and service worker contexts. That is intentional: initial registration is likely to trigger some permission request UI that needs to happen in a document (tab) context. Subsequent re-registration will not require re-prompting if the user agent stored the user's permission decision. So re-registration can happen in the background in the service worker context. What problem are you alluding to?

from push-api.

@mvano that might be OK. I guess the concern reduces down to having to have registration code in both places. Since the registration process is entirely trivial, that's probably OK. Don't worry about that then.

from push-api.

The main use for the event is to allow key rotation - there are several keys/tokens that are likely to be used in the process, used for authentication, regid generation, encryption. The push server can provide a smooth transition - allow use of both old and new one for a transition period.

The second use case is when a registration can no longer be used - it may be actually lost (rare storage problems), but more likely the push server may detect cases of 2 devices using the same device ID ( due to cloning / backup-restore, etc). This case may require UI - it's typical to associate the registration id with an account, so some auth may be needed.

If a push server allows multiple senders ( channels ) - than all those channels would need to be re-registered, and the new IDs sent to the sender apps.

It is possible to have the event include a new registration ID, or some map if multiple channels are allowed - but the code may be more flexible and simpler if it's driven by client app by calling register() again. Another benefit of event + explicit register() instead of pushing a new registration id that it allow the UA to know that the app actually handled the event. For example GCM/C2DM did send a new registration ID, but many apps just ignored it or didn't properly handle the event - and we couldn't tell if this happened.

from push-api.

I guess the concern reduces down to having to have registration code in both places. Since the registration process is entirely trivial, that's probably OK. Don't worry about that then.

Agreed that registration does not require much code. But still, code reuse is better. It is also easy, as the same script can be included in the page using a script tag, and in the worker using importScripts:
http://www.w3.org/TR/workers/#importing-scripts-and-libraries

from push-api.

I'm in favor of renaming to pushregistrationchange as the name seems to convey the meaning of the event well, and it fits well with existing event names. If there are no objections, I'll change it in the spec.

@efullea I hope you've seen this discussion.

from push-api.

+1 pushregistrationchange

from push-api.

Note that following issue #98 this will become pushsubscriptionchange.

from push-api.