Re: [w3c/push-api] Progressing spec to CR (#334)

#303 - Probably worth fixing here if we can.  This isn't really a problem that *this* specification needs to fix, but the IETF documents aren't exactly open for business.  I don't know if we can recommend that UA transitively insist that push services accept POST with CORS headers (Access-Control-Allow-* etc...), but I guess we could at least suggest that it might be a good idea.

#300 - I think we can close/defer this.  It is entirely possible for a push message to get through, with the app unable to access the network in order to do what it thinks is necessary based on that message. That will not result in the SW being woken again, but there are other options (background sync was quoted, but I think that died on the vine; timers are potentially possible also).  Ultimately, this is an error condition that apps just need to deal with.

#280 - I think that the ship sailed on this.  Anne is right to insist on better here, but I don't see this as a barrier to CR.

#292 - Defer.  This is not a bad idea, but unless browsers are implementing it, I don't see a need for it.  In practice, it seems like subscriptions are effectively perpetual, so the need for something like this is somewhat academic.  Those cases that really need a change (database compromise, for instance) can probably tolerate a small window where messages might get lost.

-- 
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/push-api/issues/334#issuecomment-948314392