[aerogear-dev] GSoC plan for WebPush

Idel Pivnitskiy idel.pivnitskiy at gmail.com
Wed May 18 06:48:45 EDT 2016


>
> 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_support
>> 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:
>
> https://github.com/aerogear/aerogear-js/blob/master/src/simplepush/aerogear.simplepush.js#L27
>

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
--
Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>

On Tue, May 17, 2016 at 9:29 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
> On Tue, May 17, 2016 at 7:03 PM, Idel Pivnitskiy <
> idel.pivnitskiy at 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_support
>> 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:
>
> https://github.com/aerogear/aerogear-js/blob/master/src/simplepush/aerogear.simplepush.js#L27
>
>
>
>>
>> Best regards,
>> Idel Pivnitskiy
>> --
>> Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
>> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
>>
>> On Tue, May 17, 2016 at 7:45 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>>
>>>
>>> On Tue, May 17, 2016 at 6:03 PM, Idel Pivnitskiy <
>>> idel.pivnitskiy at 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 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
>>>> --
>>>> Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
>>>> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
>>>>
>>>> On Tue, May 17, 2016 at 6:38 PM, Matthias Wessendorf <matzew at apache.org
>>>> > wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 17, 2016 at 5:33 PM, Idel Pivnitskiy <
>>>>> idel.pivnitskiy at 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, 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
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> twitter: http://twitter.com/mwessendorf
>>>>>
>>>>> _______________________________________________
>>>>> 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/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> _______________________________________________
>>> 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/
> sessions: http://www.slideshare.net/mwessendorf
> 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/20160518/348ab792/attachment.html 


More information about the aerogear-dev mailing list