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!But I think that it will not work with Chrome now: https://developer.mozilla.org/en-US/docs/Web/API/Push_API/Using_the_Push_API#Extra_steps_for_Chrome_supportHope 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:
On Tue, May 17, 2016 at 7:03 PM, Idel Pivnitskiy <idel.pivnitskiy@gmail.com> 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!But I think that it will not work with Chrome now: https://developer.mozilla.org/en-US/docs/Web/API/Push_API/Using_the_Push_API#Extra_steps_for_Chrome_supportHope 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:On Tue, May 17, 2016 at 7:45 PM, Matthias Wessendorf <matzew@apache.org> wrote:On Tue, May 17, 2016 at 6:03 PM, Idel Pivnitskiy <idel.pivnitskiy@gmail.com> 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 thisI 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 generalOn Tue, May 17, 2016 at 6:38 PM, Matthias Wessendorf <matzew@apache.org> wrote:Hi,On Tue, May 17, 2016 at 5:33 PM, Idel Pivnitskiy <idel.pivnitskiy@gmail.com> 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, butAnother 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?
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev--Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev--Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev--Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev