[aerogear-dev] GSoC plan for WebPush

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] GSoC plan for WebPush

Idel Pivnitskiy
Hi all,

I've come back from the little vocation and ready for the work on my GSoC project.

What will be our plan?
I may work according to my proposal: the first steps will be the adding WebPush support for Chrome and Firefox directly to UPS (through Google Cloud Messaging and Mozilla Push Service).
Another way: I may begin my work from WebPush Server.

If we will begin from UPS, from which branch should I work? And for which release?

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
|

Re: [aerogear-dev] GSoC plan for WebPush

Matthias Wessendorf
Hi,



On Tue, May 17, 2016 at 5:33 PM, Idel Pivnitskiy <[hidden email]> wrote:
Hi all,

I've come back from the little vocation and ready for the work on my GSoC project.

What will be our plan?
I may work according to my proposal: the first steps will be the adding WebPush support for Chrome and Firefox directly to UPS (through Google Cloud Messaging and Mozilla Push Service).

I like that, but
 
Another way: I may begin my work from WebPush Server.

Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 


At the end of the day, UPS is just another 'driver', triggering the push ?


Oh, I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

 

If we will begin from UPS, from which branch should I work? And for which release?

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
|

Re: [aerogear-dev] GSoC plan for WebPush

Idel Pivnitskiy
Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 

I think that we don't need our WebPush Server for Chrome/Firefox support. Because it possible to send push messages to Chrome only through GCM, using their API-key.
 
I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

Think that it could be done at the end of the summer, if there are no reasons to keep it. After or during the integration of WebPush Server to UPS. I prefer after, like it was with Doclet and Miredot.



Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 6:38 PM, Matthias Wessendorf <[hidden email]> wrote:
Hi,



On Tue, May 17, 2016 at 5:33 PM, Idel Pivnitskiy <[hidden email]> wrote:
Hi all,

I've come back from the little vocation and ready for the work on my GSoC project.

What will be our plan?
I may work according to my proposal: the first steps will be the adding WebPush support for Chrome and Firefox directly to UPS (through Google Cloud Messaging and Mozilla Push Service).

I like that, but
 
Another way: I may begin my work from WebPush Server.

Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 


At the end of the day, UPS is just another 'driver', triggering the push ?


Oh, I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

 

If we will begin from UPS, from which branch should I work? And for which release?

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
|

Re: [aerogear-dev] GSoC plan for WebPush

Matthias Wessendorf


On Tue, May 17, 2016 at 6:03 PM, Idel Pivnitskiy <[hidden email]> wrote:
Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 

I think that we don't need our WebPush Server for Chrome/Firefox support. Because it possible to send push messages to Chrome only through GCM, using their API-key.

Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.

E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Not a high priority, but IMO worth to think about this
 
 
I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

Think that it could be done at the end of the summer, if there are no reasons to keep it. After or during the integration of WebPush Server to UPS. I prefer after, like it was with Doclet and Miredot.

+1 makes sense to remove SimplePush, once WebPush is around. WebPush is the successor of SimplePush in general  



Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 6:38 PM, Matthias Wessendorf <[hidden email]> wrote:
Hi,



On Tue, May 17, 2016 at 5:33 PM, Idel Pivnitskiy <[hidden email]> wrote:
Hi all,

I've come back from the little vocation and ready for the work on my GSoC project.

What will be our plan?
I may work according to my proposal: the first steps will be the adding WebPush support for Chrome and Firefox directly to UPS (through Google Cloud Messaging and Mozilla Push Service).

I like that, but
 
Another way: I may begin my work from WebPush Server.

Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 


At the end of the day, UPS is just another 'driver', triggering the push ?


Oh, I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

 

If we will begin from UPS, from which branch should I work? And for which release?

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
|

Re: [aerogear-dev] GSoC plan for WebPush

Idel Pivnitskiy
Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.
E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Yes, good case!
Hope that it will be possible with Firefox, but I need to double check it.

Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 7:45 PM, Matthias Wessendorf <[hidden email]> wrote:


On Tue, May 17, 2016 at 6:03 PM, Idel Pivnitskiy <[hidden email]> wrote:
Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 

I think that we don't need our WebPush Server for Chrome/Firefox support. Because it possible to send push messages to Chrome only through GCM, using their API-key.

Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.

E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Not a high priority, but IMO worth to think about this
 
 
I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

Think that it could be done at the end of the summer, if there are no reasons to keep it. After or during the integration of WebPush Server to UPS. I prefer after, like it was with Doclet and Miredot.

+1 makes sense to remove SimplePush, once WebPush is around. WebPush is the successor of SimplePush in general  



Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 6:38 PM, Matthias Wessendorf <[hidden email]> wrote:
Hi,



On Tue, May 17, 2016 at 5:33 PM, Idel Pivnitskiy <[hidden email]> wrote:
Hi all,

I've come back from the little vocation and ready for the work on my GSoC project.

What will be our plan?
I may work according to my proposal: the first steps will be the adding WebPush support for Chrome and Firefox directly to UPS (through Google Cloud Messaging and Mozilla Push Service).

I like that, but
 
Another way: I may begin my work from WebPush Server.

Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 


At the end of the day, UPS is just another 'driver', triggering the push ?


Oh, I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

 

If we will begin from UPS, from which branch should I work? And for which release?

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
|

Re: [aerogear-dev] GSoC plan for WebPush

Matthias Wessendorf

On Tue, May 17, 2016 at 7:03 PM, Idel Pivnitskiy <[hidden email]> wrote:
Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.
E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Yes, good case!
Hope that it will be possible with Firefox, but I need to double check it.

We could offer a little decorator, if the user explicitly wants a customer server :)

We did that for simple push too:

 

Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 7:45 PM, Matthias Wessendorf <[hidden email]> wrote:


On Tue, May 17, 2016 at 6:03 PM, Idel Pivnitskiy <[hidden email]> wrote:
Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 

I think that we don't need our WebPush Server for Chrome/Firefox support. Because it possible to send push messages to Chrome only through GCM, using their API-key.

Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.

E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Not a high priority, but IMO worth to think about this
 
 
I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

Think that it could be done at the end of the summer, if there are no reasons to keep it. After or during the integration of WebPush Server to UPS. I prefer after, like it was with Doclet and Miredot.

+1 makes sense to remove SimplePush, once WebPush is around. WebPush is the successor of SimplePush in general  



Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 6:38 PM, Matthias Wessendorf <[hidden email]> wrote:
Hi,



On Tue, May 17, 2016 at 5:33 PM, Idel Pivnitskiy <[hidden email]> wrote:
Hi all,

I've come back from the little vocation and ready for the work on my GSoC project.

What will be our plan?
I may work according to my proposal: the first steps will be the adding WebPush support for Chrome and Firefox directly to UPS (through Google Cloud Messaging and Mozilla Push Service).

I like that, but
 
Another way: I may begin my work from WebPush Server.

Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 


At the end of the day, UPS is just another 'driver', triggering the push ?


Oh, I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

 

If we will begin from UPS, from which branch should I work? And for which release?

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
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] GSoC plan for WebPush

Idel Pivnitskiy
Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.
E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Yes, good case!
Hope that it will be possible with Firefox, but I need to double check it.

We could offer a little decorator, if the user explicitly wants a customer server :)

We did that for simple push too:

Great!

So, I will begin to implement Chrome support for UPS, right? PR against master? Will we create JIRAs? Which labels should I use?

Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 9:29 PM, Matthias Wessendorf <[hidden email]> wrote:

On Tue, May 17, 2016 at 7:03 PM, Idel Pivnitskiy <[hidden email]> wrote:
Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.
E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Yes, good case!
Hope that it will be possible with Firefox, but I need to double check it.

We could offer a little decorator, if the user explicitly wants a customer server :)

We did that for simple push too:

 

Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 7:45 PM, Matthias Wessendorf <[hidden email]> wrote:


On Tue, May 17, 2016 at 6:03 PM, Idel Pivnitskiy <[hidden email]> wrote:
Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 

I think that we don't need our WebPush Server for Chrome/Firefox support. Because it possible to send push messages to Chrome only through GCM, using their API-key.

Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.

E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Not a high priority, but IMO worth to think about this
 
 
I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

Think that it could be done at the end of the summer, if there are no reasons to keep it. After or during the integration of WebPush Server to UPS. I prefer after, like it was with Doclet and Miredot.

+1 makes sense to remove SimplePush, once WebPush is around. WebPush is the successor of SimplePush in general  



Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 6:38 PM, Matthias Wessendorf <[hidden email]> wrote:
Hi,



On Tue, May 17, 2016 at 5:33 PM, Idel Pivnitskiy <[hidden email]> wrote:
Hi all,

I've come back from the little vocation and ready for the work on my GSoC project.

What will be our plan?
I may work according to my proposal: the first steps will be the adding WebPush support for Chrome and Firefox directly to UPS (through Google Cloud Messaging and Mozilla Push Service).

I like that, but
 
Another way: I may begin my work from WebPush Server.

Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 


At the end of the day, UPS is just another 'driver', triggering the push ?


Oh, I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

 

If we will begin from UPS, from which branch should I work? And for which release?

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


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

Re: [aerogear-dev] GSoC plan for WebPush

Matthias Wessendorf


On Wed, May 18, 2016 at 12:48 PM, Idel Pivnitskiy <[hidden email]> wrote:
Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.
E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Yes, good case!
Hope that it will be possible with Firefox, but I need to double check it.

We could offer a little decorator, if the user explicitly wants a customer server :)

We did that for simple push too:

Great!

So, I will begin to implement Chrome support for UPS, right? PR against master?

sounds good to me!

For HTTP/2 I think we may need to add instructions about adding the jetty-alpn-agent, for getting WF-10 up and running 
 
Will we create JIRAs? Which labels should I use?

Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 9:29 PM, Matthias Wessendorf <[hidden email]> wrote:

On Tue, May 17, 2016 at 7:03 PM, Idel Pivnitskiy <[hidden email]> wrote:
Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.
E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Yes, good case!
Hope that it will be possible with Firefox, but I need to double check it.

We could offer a little decorator, if the user explicitly wants a customer server :)

We did that for simple push too:

 

Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 7:45 PM, Matthias Wessendorf <[hidden email]> wrote:


On Tue, May 17, 2016 at 6:03 PM, Idel Pivnitskiy <[hidden email]> wrote:
Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 

I think that we don't need our WebPush Server for Chrome/Firefox support. Because it possible to send push messages to Chrome only through GCM, using their API-key.

Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.

E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Not a high priority, but IMO worth to think about this
 
 
I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

Think that it could be done at the end of the summer, if there are no reasons to keep it. After or during the integration of WebPush Server to UPS. I prefer after, like it was with Doclet and Miredot.

+1 makes sense to remove SimplePush, once WebPush is around. WebPush is the successor of SimplePush in general  



Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 6:38 PM, Matthias Wessendorf <[hidden email]> wrote:
Hi,



On Tue, May 17, 2016 at 5:33 PM, Idel Pivnitskiy <[hidden email]> wrote:
Hi all,

I've come back from the little vocation and ready for the work on my GSoC project.

What will be our plan?
I may work according to my proposal: the first steps will be the adding WebPush support for Chrome and Firefox directly to UPS (through Google Cloud Messaging and Mozilla Push Service).

I like that, but
 
Another way: I may begin my work from WebPush Server.

Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 


At the end of the day, UPS is just another 'driver', triggering the push ?


Oh, I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

 

If we will begin from UPS, from which branch should I work? And for which release?

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


_______________________________________________
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
|

Re: [aerogear-dev] GSoC plan for WebPush

Matthias Wessendorf
@JIRA: sure, please on AGPUSH; we can use the label 'gsoc-webpush' ? 

On Wed, May 18, 2016 at 1:31 PM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, May 18, 2016 at 12:48 PM, Idel Pivnitskiy <[hidden email]> wrote:
Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.
E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Yes, good case!
Hope that it will be possible with Firefox, but I need to double check it.

We could offer a little decorator, if the user explicitly wants a customer server :)

We did that for simple push too:

Great!

So, I will begin to implement Chrome support for UPS, right? PR against master?

sounds good to me!

For HTTP/2 I think we may need to add instructions about adding the jetty-alpn-agent, for getting WF-10 up and running 
 
Will we create JIRAs? Which labels should I use?

Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 9:29 PM, Matthias Wessendorf <[hidden email]> wrote:

On Tue, May 17, 2016 at 7:03 PM, Idel Pivnitskiy <[hidden email]> wrote:
Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.
E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Yes, good case!
Hope that it will be possible with Firefox, but I need to double check it.

We could offer a little decorator, if the user explicitly wants a customer server :)

We did that for simple push too:

 

Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 7:45 PM, Matthias Wessendorf <[hidden email]> wrote:


On Tue, May 17, 2016 at 6:03 PM, Idel Pivnitskiy <[hidden email]> wrote:
Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 

I think that we don't need our WebPush Server for Chrome/Firefox support. Because it possible to send push messages to Chrome only through GCM, using their API-key.

Right, but that goes through their service. I think one of the big advantages here is that with a truly open WebPush Server/Protocol/API, you as a company, can run your own, inpendent push network. Having support to connect to a custom WebPush server from the (standard?) JS API would be nice. Makes you more independent.

E.g. imagine push on a private network, where not all devcies are connected to the public internet ;-)

Not a high priority, but IMO worth to think about this
 
 
I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

Think that it could be done at the end of the summer, if there are no reasons to keep it. After or during the integration of WebPush Server to UPS. I prefer after, like it was with Doclet and Miredot.

+1 makes sense to remove SimplePush, once WebPush is around. WebPush is the successor of SimplePush in general  



Best regards,
Idel Pivnitskiy
--

On Tue, May 17, 2016 at 6:38 PM, Matthias Wessendorf <[hidden email]> wrote:
Hi,



On Tue, May 17, 2016 at 5:33 PM, Idel Pivnitskiy <[hidden email]> wrote:
Hi all,

I've come back from the little vocation and ready for the work on my GSoC project.

What will be our plan?
I may work according to my proposal: the first steps will be the adding WebPush support for Chrome and Firefox directly to UPS (through Google Cloud Messaging and Mozilla Push Service).

I like that, but
 
Another way: I may begin my work from WebPush Server.

Does it make sense starting with more focused examples? Showing Chrome/Firefox receiving message via the WebPush APIs from the standalone WebPush Server ? 


At the end of the day, UPS is just another 'driver', triggering the push ?


Oh, I think we can also remove the SimplePush from the master branch of UPS, while on this project, no ? 

 

If we will begin from UPS, from which branch should I work? And for which release?

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


_______________________________________________
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