[aerogear-dev] Firefox Push API with UnifiedPush Server

Tue Jul 26 06:16:20 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 ?

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