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]
On Mon, Jul 25, 2016 at 5:21 PM, Idel Pivnitskiy <idel.pivnitskiy(a)gmail.com>
wrote:
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>
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(a)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.
>>
>> [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
>