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
--

On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist <lholmqui@redhat.com> wrote:
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@gmail.com> wrote:
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.


Best regards,
Idel Pivnitskiy
--

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev