Quantcast

[aerogear-dev] Firefox Push API with UnifiedPush Server

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[aerogear-dev] Firefox Push API with UnifiedPush Server

Idel Pivnitskiy
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Firefox Push API with UnifiedPush Server

Luke Holmquist
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Firefox Push API with UnifiedPush Server

Idel Pivnitskiy
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?


Best regards,
Idel Pivnitskiy
--

On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Firefox Push API with UnifiedPush Server

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

On Mon, Jul 25, 2016 at 5:21 PM, Idel Pivnitskiy <[hidden email]> 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?


Best regards,
Idel Pivnitskiy
--

On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Firefox Push API with UnifiedPush Server

Matthias Wessendorf
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 <[hidden email]> 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
--

On Mon, Jul 25, 2016 at 5:21 PM, Idel Pivnitskiy <[hidden email]> 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?


Best regards,
Idel Pivnitskiy
--

On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Firefox Push API with UnifiedPush Server

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

On Tue, Jul 26, 2016 at 1:16 PM, Matthias Wessendorf <[hidden email]> 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 <[hidden email]> 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
--

On Mon, Jul 25, 2016 at 5:21 PM, Idel Pivnitskiy <[hidden email]> 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?


Best regards,
Idel Pivnitskiy
--

On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Firefox Push API with UnifiedPush Server

Idel Pivnitskiy
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 :)

[2] https://github.com/aerogear/aerogear-js-cookbook/pull/15

Best regards,
Idel Pivnitskiy
--

On Tue, Jul 26, 2016 at 1:48 PM, Idel Pivnitskiy <[hidden email]> 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

On Tue, Jul 26, 2016 at 1:16 PM, Matthias Wessendorf <[hidden email]> 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 <[hidden email]> 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
--

On Mon, Jul 25, 2016 at 5:21 PM, Idel Pivnitskiy <[hidden email]> 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?


Best regards,
Idel Pivnitskiy
--

On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Firefox Push API with UnifiedPush Server

Matthias Wessendorf
yay!

On Thu, Jul 28, 2016 at 2:13 AM, Idel Pivnitskiy <[hidden email]> 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 :)

[2] https://github.com/aerogear/aerogear-js-cookbook/pull/15

Best regards,
Idel Pivnitskiy
--

On Tue, Jul 26, 2016 at 1:48 PM, Idel Pivnitskiy <[hidden email]> 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

On Tue, Jul 26, 2016 at 1:16 PM, Matthias Wessendorf <[hidden email]> 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 <[hidden email]> 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
--

On Mon, Jul 25, 2016 at 5:21 PM, Idel Pivnitskiy <[hidden email]> 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?


Best regards,
Idel Pivnitskiy
--

On Mon, Jul 25, 2016 at 4:25 PM, Luke Holmquist <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Loading...