Re: [aerogear-dev] Firefox Push API with UnifiedPush Server

Can't we just name the variant a "WebPush", with a special field for the user to provide info, WHAT provider will be used? e.g. on that WebPush Variant; TYPE: Firefox ? On Tue, Jul 26, 2016 at 12:15 AM, Idel Pivnitskiy <idel.pivnitskiy(a)gmail.com > I've sent a separate PR with renamed Firefox Variant to Webpush Variant > [1]. Will try to make it workable with Google Chrome and FCM too tomorrow. > > [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/745 > > Best regards, > Idel Pivnitskiy > -- > Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy> > GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy> > > On Mon, Jul 25, 2016 at 5:21 PM, Idel Pivnitskiy < > idel.pivnitskiy(a)gmail.com> >> It's a bit early to talk about Safari, because it has not implemented >> Push API, Service Worker API and push message encryption yet. And no >> information about their plans to do this. Currently Apple uses their own >> protocol for push notifications. I've asked my friend to register a test >> app from his Apple developer's account for me, and I'm going to test how it >> will work now, with APNs Variant. >> >> Here is info, that Microsoft started development of Push API for Edge [1]. >> >> I decided to create a variant for Firefox just because variant saves >> authentication tokens for push service provider and later uses it's own >> notification sender for a specific push service provider. And I started to >> work on this, when here was no info that Chrome supports PushMessageData >> and push message encryption. But now it may be reasonable to create a >> WebPush variant. Or wait Push API in Edge and decide how to move forward >> after the third player in the game. >> >> If we will create WebPush variant the advantages are: >> >> 1. User have to create just one variant >> 2. Unique extended Installation entity with "auth secret" and "public >> key" from the browser. >> >> but disadvantages are: >> >> 1. Required registration on each push notification provider: FCM, >> MPS, etc. (but advantage that the user will not forgot something) >> 2. Determine browser on client side, store it in Installation during >> registration of device and make decision which push notification provider >> should be chosen before sending each message. >> >> If we will create variant for each push notification provider the >> advantages are: >> >> 1. Keep our rule, that each variant has it's own push message >> provider and auth information. >> >> but disadvantages are: >> >> 1. Determine browser on client side and choose appropriate variant >> secret. >> 2. For FCM make decision about should we encrypt the message before >> sent (if the client is Chrome) or not. >> >> Also here is a chance, that FCM, MPS and others will implement totally >> identical push services, according to the specification [2], with >> acknowledgment, receipts, HTTP/2, etc. So it may be reasonable to focus on >> one WebPush variant. It will not be a problem for me to rename Firefox to >> WebPush now. I can open a separate PR this evening. >> >> Any thoughts? >> >> [1] >> https://developer.microsoft.com/en-us/microsoft-edge/platform/status/pushapi >> [2] https://tools.ietf.org/html/draft-ietf-webpush-protocol >> >> Best regards, >> Idel Pivnitskiy >> -- >> Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy> >> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy> >> >> On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist <lholmqui(a)redhat.com&gt; >>> >>> I'm tempted to say that there should be a "WebPush" variant instead >>> which could be chrome/ff/safari, but i think chrome and safari are to >>> closely related to Android/iOS atm that it wouldn't make sense. >>> >>> Somewhat related to this is the JS SDK for the ups and how it works for >>> push on the web. It was initially created to just handle registering >>> SimplePush clients, since there was no browsers doing push. Then Safari >>> introduced push, then chrome and FF. with regards to the UPS, these are 3 >>> different variants, so to create 1 app that handles all three you would >>> need to make sure to register 3 "clients" in the js sdk. I don't know if >>> there is anyway we can help the user out with this. Safari is different >>> enough that it would be easy for the user, but there is no real difference >>> between the registration code in FF and chrome.(perhaps these 2 should be >>> the "WebPush" variant) so a user agent parse would probably need to >>> happen. i'm not really a big fan of including that in the library, but >>> maybe we should have an example that shows push for FF and chrome in the >>> same example. >>> >>> >>> >>> On Sun, Jul 24, 2016 at 9:05 PM, Idel Pivnitskiy < >>> idel.pivnitskiy(a)gmail.com>>> >>>> Hi all, >>>> >>>> I've added a Firefox Variant to support Push API in Mozilla Firefox for >>>> UPS [1]. It works well with my previous example for Chrome [2]. I also >>>> created a new PR to adapt comments in this example and notice that Firefox >>>> also supported [3]. >>>> >>>> Current implementation of Firefox Variant does not support >>>> PushMessageData [4]. Looks like it will require significant changes of UPS. >>>> I will initiate a separate thread for this discussion. >>>> >>>> [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/744 >>>> [2] https://github.com/aerogear/aerogear-js-cookbook/pull/13 >>>> [3] https://github.com/aerogear/aerogear-js-cookbook/pull/14 >>>> [4] https://developer.mozilla.org/en-US/docs/Web/API/PushMessageData >>>> >>>> Best regards, >>>> Idel Pivnitskiy >>>> -- >>>> Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy> >>>> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ twitter: http://twitter.com/mwessendorf