[aerogear-dev] Firefox Push API with UnifiedPush Server

Tue Jul 26 06:48:40 EDT 2016

>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160726/1db483f4/attachment.html 