Hi Martin, note that the latest proposal is to have only a single registration at a time: http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0223.html
This means that unregister can remain on PushManager and requires no arguments. Yesterday I also posted a github issue with the suggestion to change the unregister return value: https://github.com/w3c/push-api/issues/4 Respec was fixed recently to support parameterization after this discussion: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0697.html Regards, Michael On Tue, May 13, 2014 at 6:10 PM, Martin Thomson <martin.thom...@gmail.com>wrote: > On 13 May 2014 06:39, Michael van Ouwerkerk <mvanouwerk...@google.com> > wrote: > > Martin, in Chrome we use registrationId and endpoint for distinct > purposes. > > The endpoint is the push server url to which the app server posts new > > messages. The registrationId identifies the correct {device, user, page} > to > > which the message will be sent. > > I think that the spec needs to be a lot clearer on the purpose (and > usage) of each of these things. Personally, I think that a better > model would be this: > > interface PushManager { > Promise<PushRegistration> register(); > Promise<sequence<PushRegistration>> registrations(); > }; > > interface PushRegistration { > Promise unregister(); > attribute DOMString id; > attribute DOMString endpoint; > }; > > interface PushMessage { > attribute PushRegistration registration; > attribute ?? data; > } > > Yes, aside from moving unregister, it's just names, but sometimes > names are important. The reason behind moving unregister being that > 'id' is only present for bookkeeping purposes, and many apps won't > have to use it. > > That said, looking at this, I am sorely tempted to suggest adding > EventTarget to PushRegistration and use events. Any reason that > wouldn't be appropriate? > > p.s., I assume that the mess in the editor's draft regarding > PushManager is due to a Respec.js issue around the use of promises. >
