[aerogear-dev] Firefox Push API with UnifiedPush Server

Thu Jul 28 00:49:26 EDT 2016

yay!

On Thu, Jul 28, 2016 at 2:13 AM, Idel Pivnitskiy <idel.pivnitskiy at gmail.com>
wrote:

> I've improved WebPushNotificationSender. Now it can send push
> notifications to both push notification providers: FCM and MPS. See the
> last commit in this PR [1].
>
> I also updated a demo web app for Push API [2]. Everything works perfect
> in Chrome and Firefox with UPS and WebPush Variant :)
>
> [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/745
> [2] https://github.com/aerogear/aerogear-js-cookbook/pull/15
>
> Best regards,
> Idel Pivnitskiy
> --
> Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
>
> On Tue, Jul 26, 2016 at 1:48 PM, Idel Pivnitskiy <
> idel.pivnitskiy at gmail.com> wrote:
>
>> 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 ?
>>
>>
>> Provider should be defined for each Installation
>> (device/client/endpoint), not for the whole Variant.
>>
>> Best regards,
>> Idel Pivnitskiy
>> --
>> Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
>> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
>>
>> On Tue, Jul 26, 2016 at 1:16 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> 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 at gmail.com> wrote:
>>>
>>>> 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 at 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 at 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 at 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 at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160728/612130ce/attachment.html 