Yeap on it. On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > Hi, > > The Advanced Analytics task[1] has a new PR[2] that has been rebased on > the latest master and got a lot of polishing. > > Could the Client Tech Leads take a look at it [3] and review ? The only > "breaking" change is the rename of the header's name that identifies a Push > Notification, it's called now "aerogear-push-id" > > Seb > > > > [1] https://issues.jboss.org/browse/AGPUSH-971 > [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540 > [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >

Hi Corinne ! We want to collect for both situations you described :) Envoyé de mon iPhone Le 4 mai 2015 à 17:53, Corinne Krych <corinnekrych(a)gmail.com&gt; a écrit : Hello Sebi, After giving it a closer look, I've got a question for you: do we want to collect metrics only when an app is opened via push notification or do we also want to collect metrics when an app is brought to foreground by a push notification? ++ Corinne On 4 May 2015 at 10:21, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > Yeap > on it. > > On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> Hi, >> >> The Advanced Analytics task[1] has a new PR[2] that has been rebased on >> the latest master and got a lot of polishing. >> >> Could the Client Tech Leads take a look at it [3] and review ? The only >> "breaking" change is the rename of the header's name that identifies a Push >> Notification, it's called now "aerogear-push-id" >> >> Seb >> >> >> >> [1] https://issues.jboss.org/browse/AGPUSH-971 >> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540 >> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971 >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I agree with this and maybe we want even more functionality moved, because also updating the categories is strange in a 'register' method. Say for instance you want to change the categories your interested in a developer has to call register again?

And if I understand Corinnes mail that will currently not even work on iOS. For cordova I store the device info, because the lifecycle is different, but that is okay it's an integration problem. So updating the installation details should be a separate method that also contains updating the categories. That way we have a better split between a device that registers itself with UPS and updating the subscription data.

On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > Hello Sebi, > > > I've done an initial work on aerogear-ios-push [swift branch], adding a new > parameter when doing the registration to pass the ag-push-id. See: > > https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...c... > > This client could be tested with HelloWorld. See: > > https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mob... > > What is not covered is the background app coming to foreground through a > push notification. If you look at HelloWorld: > > https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e09332... > > In iOS, when we go from background to foreground we don't go through > registration API. The iOS push lib doesn't store locally (as opposed to > windows sdk for ex) the device information. So i can't really make another > call to registration API. What i'd suggest is to have a separate endpoint > for metrics instead of having it coupled with registration endpoint. wdyt? > > ++ > > Corinne > > On 4 May 2015 at 19:07, Sébastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> >> Hi Corinne ! >> We want to collect for both situations you described :) >> >> Envoyé de mon iPhone >> >> Le 4 mai 2015 à 17:53, Corinne Krych <corinnekrych(a)gmail.com&gt; a écrit : >> >> Hello Sebi, >> >> After giving it a closer look, I've got a question for you: do we want to >> collect metrics only when an app is opened via push notification or do we >> also want to collect metrics when an app is brought to foreground by a push >> notification? >> >> ++ >> Corinne >> >> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: >>> >>> Yeap >>> on it. >>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>> >>>> Hi, >>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased on >>>> the latest master and got a lot of polishing. >>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The only >>>> "breaking" change is the rename of the header's name that identifies a Push >>>> Notification, it's called now "aerogear-push-id" >>>> >>>> Seb >>>> >>>> >>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971 >>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540 >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971 >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Cheers, Erik Jan _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

To give a bit of background on this background to foreground issue :)) Push Cordova plugin matches Cordova life cycle by storing some information locally see: https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGP... Doing so allows you to call multiple time registration, even when an app comes back from background to foreground. you can do it because you have stored locally all the information neede for registration. But when dealing directly with native apps, the life cycle does not always goes through a registration. To sort out this issue,we can: - either store locally at the ios-push lib level instead of doing it in Cordova plugin and then call registration API on all delegate methods (even though we don't want to register but just send the metrics) - or leave the ios-push lib without any storage and provide a separate endpoint for sending metrics or changing categories. I'd go for the second option. ++ Corinne On 5 May 2015 at 10:39, Erik Jan de Wit <edewit(a)redhat.com&gt; wrote: > I agree with this and maybe we want even more functionality moved, > because also updating the categories is strange in a 'register' > method. Say for instance you want to change the categories your > interested in a developer has to call register again? And if I > understand Corinnes mail that will currently not even work on iOS. > > For cordova I store the device info, because the lifecycle is > different, but that is okay it's an integration problem. > > So updating the installation details should be a separate method that > also contains updating the categories. That way we have a better split > between a device that registers itself with UPS and updating the > subscription data. > > > On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; > wrote: > > Hello Sebi, > > > > > > I've done an initial work on aerogear-ios-push [swift branch], adding a > new > > parameter when doing the registration to pass the ag-push-id. See: > > > > > https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...c... > > > > This client could be tested with HelloWorld. See: > > > > > https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mob... > > > > What is not covered is the background app coming to foreground through a > > push notification. If you look at HelloWorld: > > > > > https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e09332... > > > > In iOS, when we go from background to foreground we don't go through > > registration API. The iOS push lib doesn't store locally (as opposed to > > windows sdk for ex) the device information. So i can't really make > another > > call to registration API. What i'd suggest is to have a separate > endpoint > > for metrics instead of having it coupled with registration endpoint. > wdyt? > > > > ++ > > > > Corinne > > > > On 4 May 2015 at 19:07, Sébastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> > >> Hi Corinne ! > >> We want to collect for both situations you described :) > >> > >> Envoyé de mon iPhone > >> > >> Le 4 mai 2015 à 17:53, Corinne Krych <corinnekrych(a)gmail.com&gt; a écrit > : > >> > >> Hello Sebi, > >> > >> After giving it a closer look, I've got a question for you: do we want > to > >> collect metrics only when an app is opened via push notification or do > we > >> also want to collect metrics when an app is brought to foreground by a > push > >> notification? > >> > >> ++ > >> Corinne > >> > >> > >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > >>> > >>> Yeap > >>> on it. > >>> > >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > wrote: > >>>> > >>>> Hi, > >>>> > >>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased > on > >>>> the latest master and got a lot of polishing. > >>>> > >>>> Could the Client Tech Leads take a look at it [3] and review ? The > only > >>>> "breaking" change is the rename of the header's name that identifies > a Push > >>>> Notification, it's called now "aerogear-push-id" > >>>> > >>>> Seb > >>>> > >>>> > >>>> > >>>> [1] https://issues.jboss.org/browse/AGPUSH-971 > >>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540 > >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971 > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev(a)lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Cheers, > Erik Jan > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >

On Tue, May 5, 2015 at 11:53 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > To give a bit of background on this background to foreground issue :)) > > Push Cordova plugin matches Cordova life cycle by storing some > information locally see: > > https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGP... > Doing so allows you to call multiple time registration, even when an app > comes back from background to foreground. you can do it because you have > stored locally all the information neede for registration. > > But when dealing directly with native apps, the life cycle does not > always goes through a registration. > > To sort out this issue,we can: > - either store locally at the ios-push lib level instead of doing it in > Cordova plugin and then call registration API on all delegate methods (even > though we don't want to register but just send the metrics) > - or leave the ios-push lib without any storage and provide a separate > endpoint for sending metrics or changing categories. > > I'd go for the second option. > > second option makes sense +1

- Christos > > > On 5 May 2015 at 10:39, Erik Jan de Wit <edewit(a)redhat.com&gt; wrote: > >> I agree with this and maybe we want even more functionality moved, >> because also updating the categories is strange in a 'register' >> method. Say for instance you want to change the categories your >> interested in a developer has to call register again? And if I >> understand Corinnes mail that will currently not even work on iOS. >> >> For cordova I store the device info, because the lifecycle is >> different, but that is okay it's an integration problem. >> >> So updating the installation details should be a separate method that >> also contains updating the categories. That way we have a better split >> between a device that registers itself with UPS and updating the >> subscription data. >> >> >> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; >> wrote: >> > Hello Sebi, >> > >> > >> > I've done an initial work on aerogear-ios-push [swift branch], adding >> a new >> > parameter when doing the registration to pass the ag-push-id. See: >> > >> > >> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...c... >> > >> > This client could be tested with HelloWorld. See: >> > >> > >> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mob... >> > >> > What is not covered is the background app coming to foreground through >> a >> > push notification. If you look at HelloWorld: >> > >> > >> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e09332... >> > >> > In iOS, when we go from background to foreground we don't go through >> > registration API. The iOS push lib doesn't store locally (as opposed to >> > windows sdk for ex) the device information. So i can't really make >> another >> > call to registration API. What i'd suggest is to have a separate >> endpoint >> > for metrics instead of having it coupled with registration endpoint. >> wdyt? >> > >> > ++ >> > >> > Corinne >> > >> > On 4 May 2015 at 19:07, Sébastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> >> >> >> Hi Corinne ! >> >> We want to collect for both situations you described :) >> >> >> >> Envoyé de mon iPhone >> >> >> >> Le 4 mai 2015 à 17:53, Corinne Krych <corinnekrych(a)gmail.com&gt; a >> écrit : >> >> >> >> Hello Sebi, >> >> >> >> After giving it a closer look, I've got a question for you: do we >> want to >> >> collect metrics only when an app is opened via push notification or >> do we >> >> also want to collect metrics when an app is brought to foreground by >> a push >> >> notification? >> >> >> >> ++ >> >> Corinne >> >> >> >> >> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: >> >>> >> >>> Yeap >> >>> on it. >> >>> >> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> The Advanced Analytics task[1] has a new PR[2] that has been >> rebased on >> >>>> the latest master and got a lot of polishing. >> >>>> >> >>>> Could the Client Tech Leads take a look at it [3] and review ? The >> only >> >>>> "breaking" change is the rename of the header's name that >> identifies a Push >> >>>> Notification, it's called now "aerogear-push-id" >> >>>> >> >>>> Seb >> >>>> >> >>>> >> >>>> >> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971 >> >>>> [2] >> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540 >> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971 >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> aerogear-dev mailing list >> >>>> aerogear-dev(a)lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>> >> >>> >> >> >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> > >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Cheers, >> Erik Jan >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

yeap, a new client API performing a PUt will do well On 5 May 2015 at 11:17, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > On Tue, May 5, 2015 at 11:09 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; > wrote: > >> >> >> On Tue, May 5, 2015 at 11:53 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; >> wrote: >> >>> To give a bit of background on this background to foreground issue :)) >>> >>> Push Cordova plugin matches Cordova life cycle by storing some >>> information locally see: >>> >>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGP... >>> Doing so allows you to call multiple time registration, even when an >>> app comes back from background to foreground. you can do it because you >>> have stored locally all the information neede for registration. >>> >>> But when dealing directly with native apps, the life cycle does not >>> always goes through a registration. >>> >>> To sort out this issue,we can: >>> - either store locally at the ios-push lib level instead of doing it in >>> Cordova plugin and then call registration API on all delegate methods (even >>> though we don't want to register but just send the metrics) >>> - or leave the ios-push lib without any storage and provide a separate >>> endpoint for sending metrics or changing categories. >>> >>> I'd go for the second option. >>> >>> second option makes sense +1 >> > > +1 on separate endpoint for metrics collection > > regarding changing categories: Do you mean a new method on the client > SDK, performing a PUT, containing the new categories for the device token, > to the existing endpoint (but using PUT), instead of getting a > /updateInstallation endpoint? > > > >> >> - >> Christos >> >>> >>> >>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit(a)redhat.com&gt; wrote: >>> >>>> I agree with this and maybe we want even more functionality moved, >>>> because also updating the categories is strange in a 'register' >>>> method. Say for instance you want to change the categories your >>>> interested in a developer has to call register again? And if I >>>> understand Corinnes mail that will currently not even work on iOS. >>>> >>>> For cordova I store the device info, because the lifecycle is >>>> different, but that is okay it's an integration problem. >>>> >>>> So updating the installation details should be a separate method that >>>> also contains updating the categories. That way we have a better split >>>> between a device that registers itself with UPS and updating the >>>> subscription data. >>>> >>>> >>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; >>>> wrote: >>>> > Hello Sebi, >>>> > >>>> > >>>> > I've done an initial work on aerogear-ios-push [swift branch], >>>> adding a new >>>> > parameter when doing the registration to pass the ag-push-id. See: >>>> > >>>> > >>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...c... >>>> > >>>> > This client could be tested with HelloWorld. See: >>>> > >>>> > >>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mob... >>>> > >>>> > What is not covered is the background app coming to foreground >>>> through a >>>> > push notification. If you look at HelloWorld: >>>> > >>>> > >>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e09332... >>>> > >>>> > In iOS, when we go from background to foreground we don't go through >>>> > registration API. The iOS push lib doesn't store locally (as opposed >>>> to >>>> > windows sdk for ex) the device information. So i can't really make >>>> another >>>> > call to registration API. What i'd suggest is to have a separate >>>> endpoint >>>> > for metrics instead of having it coupled with registration endpoint. >>>> wdyt? >>>> > >>>> > ++ >>>> > >>>> > Corinne >>>> > >>>> > On 4 May 2015 at 19:07, Sébastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>> >> >>>> >> Hi Corinne ! >>>> >> We want to collect for both situations you described :) >>>> >> >>>> >> Envoyé de mon iPhone >>>> >> >>>> >> Le 4 mai 2015 à 17:53, Corinne Krych <corinnekrych(a)gmail.com&gt; a >>>> écrit : >>>> >> >>>> >> Hello Sebi, >>>> >> >>>> >> After giving it a closer look, I've got a question for you: do we >>>> want to >>>> >> collect metrics only when an app is opened via push notification or >>>> do we >>>> >> also want to collect metrics when an app is brought to foreground >>>> by a push >>>> >> notification? >>>> >> >>>> >> ++ >>>> >> Corinne >>>> >> >>>> >> >>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych(a)gmail.com&gt; >>>> wrote: >>>> >>> >>>> >>> Yeap >>>> >>> on it. >>>> >>> >>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>> wrote: >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been >>>> rebased on >>>> >>>> the latest master and got a lot of polishing. >>>> >>>> >>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? >>>> The only >>>> >>>> "breaking" change is the rename of the header's name that >>>> identifies a Push >>>> >>>> Notification, it's called now "aerogear-push-id" >>>> >>>> >>>> >>>> Seb >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971 >>>> >>>> [2] >>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540 >>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> aerogear-dev mailing list >>>> >>>> aerogear-dev(a)lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>>> >>> >>>> >> >>>> >> _______________________________________________ >>>> >> aerogear-dev mailing list >>>> >> aerogear-dev(a)lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> aerogear-dev mailing list >>>> >> aerogear-dev(a)lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > aerogear-dev mailing list >>>> > aerogear-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Erik Jan >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, May 5, 2015 at 5:17 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > On Tue, May 5, 2015 at 11:09 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; > wrote: > >> >> >> On Tue, May 5, 2015 at 11:53 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; >> wrote: >> >>> To give a bit of background on this background to foreground issue :)) >>> >>> Push Cordova plugin matches Cordova life cycle by storing some >>> information locally see: >>> >>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGP... >>> Doing so allows you to call multiple time registration, even when an >>> app comes back from background to foreground. you can do it because you >>> have stored locally all the information neede for registration. >>> >>> But when dealing directly with native apps, the life cycle does not >>> always goes through a registration. >>> >>> To sort out this issue,we can: >>> - either store locally at the ios-push lib level instead of doing it in >>> Cordova plugin and then call registration API on all delegate methods (even >>> though we don't want to register but just send the metrics) >>> - or leave the ios-push lib without any storage and provide a separate >>> endpoint for sending metrics or changing categories. >>> >>> I'd go for the second option. >>> >>> second option makes sense +1 >> > > +1 on separate endpoint for metrics collection > > regarding changing categories: Do you mean a new method on the client > SDK, performing a PUT, containing the new categories for the device token, > to the existing endpoint (but using PUT), instead of getting a > /updateInstallation endpoint? > Adding a separate method on Android seems kind of weird. Android is rather spammy (intentionally and by design and according to big papa G's best practices) with the registration call. Basically best practice on Android is call registration every time the application is opened.

> > >> >> - >> Christos >> >>> >>> >>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit(a)redhat.com&gt; wrote: >>> >>>> I agree with this and maybe we want even more functionality moved, >>>> because also updating the categories is strange in a 'register' >>>> method. Say for instance you want to change the categories your >>>> interested in a developer has to call register again? And if I >>>> understand Corinnes mail that will currently not even work on iOS. >>>> >>>> For cordova I store the device info, because the lifecycle is >>>> different, but that is okay it's an integration problem. >>>> >>>> So updating the installation details should be a separate method that >>>> also contains updating the categories. That way we have a better split >>>> between a device that registers itself with UPS and updating the >>>> subscription data. >>>> >>>> >>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; >>>> wrote: >>>> > Hello Sebi, >>>> > >>>> > >>>> > I've done an initial work on aerogear-ios-push [swift branch], >>>> adding a new >>>> > parameter when doing the registration to pass the ag-push-id. See: >>>> > >>>> > >>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...c... >>>> > >>>> > This client could be tested with HelloWorld. See: >>>> > >>>> > >>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mob... >>>> > >>>> > What is not covered is the background app coming to foreground >>>> through a >>>> > push notification. If you look at HelloWorld: >>>> > >>>> > >>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e09332... >>>> > >>>> > In iOS, when we go from background to foreground we don't go through >>>> > registration API. The iOS push lib doesn't store locally (as opposed >>>> to >>>> > windows sdk for ex) the device information. So i can't really make >>>> another >>>> > call to registration API. What i'd suggest is to have a separate >>>> endpoint >>>> > for metrics instead of having it coupled with registration endpoint. >>>> wdyt? >>>> > >>>> > ++ >>>> > >>>> > Corinne >>>> > >>>> > On 4 May 2015 at 19:07, Sébastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>> >> >>>> >> Hi Corinne ! >>>> >> We want to collect for both situations you described :) >>>> >> >>>> >> Envoyé de mon iPhone >>>> >> >>>> >> Le 4 mai 2015 à 17:53, Corinne Krych <corinnekrych(a)gmail.com&gt; a >>>> écrit : >>>> >> >>>> >> Hello Sebi, >>>> >> >>>> >> After giving it a closer look, I've got a question for you: do we >>>> want to >>>> >> collect metrics only when an app is opened via push notification or >>>> do we >>>> >> also want to collect metrics when an app is brought to foreground >>>> by a push >>>> >> notification? >>>> >> >>>> >> ++ >>>> >> Corinne >>>> >> >>>> >> >>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych(a)gmail.com&gt; >>>> wrote: >>>> >>> >>>> >>> Yeap >>>> >>> on it. >>>> >>> >>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>> wrote: >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been >>>> rebased on >>>> >>>> the latest master and got a lot of polishing. >>>> >>>> >>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? >>>> The only >>>> >>>> "breaking" change is the rename of the header's name that >>>> identifies a Push >>>> >>>> Notification, it's called now "aerogear-push-id" >>>> >>>> >>>> >>>> Seb >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971 >>>> >>>> [2] >>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540 >>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> aerogear-dev mailing list >>>> >>>> aerogear-dev(a)lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>>> >>> >>>> >> >>>> >> _______________________________________________ >>>> >> aerogear-dev mailing list >>>> >> aerogear-dev(a)lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> aerogear-dev mailing list >>>> >> aerogear-dev(a)lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > aerogear-dev mailing list >>>> > aerogear-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Erik Jan >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, May 5, 2015 at 12:08 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > On Tue, May 5, 2015 at 5:51 PM, Summers Pittman <supittma(a)redhat.com&gt; > wrote: > >> >> >> On Tue, May 5, 2015 at 5:17 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >>> >>> >>> On Tue, May 5, 2015 at 11:09 AM, Christos Vasilakis <cvasilak(a)gmail.com >>> > wrote: >>> >>>> >>>> >>>> On Tue, May 5, 2015 at 11:53 AM, Corinne Krych <corinnekrych(a)gmail.com >>>> > wrote: >>>> >>>>> To give a bit of background on this background to foreground issue :)) >>>>> >>>>> Push Cordova plugin matches Cordova life cycle by storing some >>>>> information locally see: >>>>> >>>>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGP... >>>>> Doing so allows you to call multiple time registration, even when an >>>>> app comes back from background to foreground. you can do it because you >>>>> have stored locally all the information neede for registration. >>>>> >>>>> But when dealing directly with native apps, the life cycle does not >>>>> always goes through a registration. >>>>> >>>>> To sort out this issue,we can: >>>>> - either store locally at the ios-push lib level instead of doing it >>>>> in Cordova plugin and then call registration API on all delegate methods >>>>> (even though we don't want to register but just send the metrics) >>>>> - or leave the ios-push lib without any storage and provide a >>>>> separate endpoint for sending metrics or changing categories. >>>>> >>>>> I'd go for the second option. >>>>> >>>>> second option makes sense +1 >>>> >>> >>> +1 on separate endpoint for metrics collection >>> >>> regarding changing categories: Do you mean a new method on the client >>> SDK, performing a PUT, containing the new categories for the device token, >>> to the existing endpoint (but using PUT), instead of getting a >>> /updateInstallation endpoint? >>> >> >> Adding a separate method on Android seems kind of weird. Android is >> rather spammy (intentionally and by design and according to big papa G's >> best practices) with the registration call. Basically best practice on >> Android is call registration every time the application is opened. >> > > I see - that relates to your earlier comment, of calling 'register' all > the time on Android/iOS as well - instead of having a update() hook. > > I do believe that having an updateDeviceMetadata() (e.g. to update the > used categories, as the end-user is no longer interested in 'rihanna') does > make sense. > I'm conflicted. I see the utility but I also want to keep the amount of mutable state to a minimum. I still think with the way Android is architected re-registering is a less error prone approach for developers. In this model when a users category changes they will regenerate the configuration using the new categories and register. This will be the same if the user is registering for the first time or not.

If we add an update method the developer will need to EITHER make sure the categories are added to the config object when it is generated when the application loads anyway OR not include category information in the registration and then call update metadata with the proper categories.

> > What about the metrics endpoint? Instead of sending that through the > registration endpoint? Agree on that or not? > I (mostly) agree on that point. Registration is an intention to subscribe not a general data submission pipeline. The thing which does metrics should probably not be part of the PushRegistrar at all.

It might make sense to make it a composite object which embeds a registrar though.

> >> >>> >>> >>>> >>>> - >>>> Christos >>>> >>>>> >>>>> >>>>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit(a)redhat.com&gt; wrote: >>>>> >>>>>> I agree with this and maybe we want even more functionality moved, >>>>>> because also updating the categories is strange in a 'register' >>>>>> method. Say for instance you want to change the categories your >>>>>> interested in a developer has to call register again? And if I >>>>>> understand Corinnes mail that will currently not even work on iOS. >>>>>> >>>>>> For cordova I store the device info, because the lifecycle is >>>>>> different, but that is okay it's an integration problem. >>>>>> >>>>>> So updating the installation details should be a separate method that >>>>>> also contains updating the categories. That way we have a better >>>>>> split >>>>>> between a device that registers itself with UPS and updating the >>>>>> subscription data. >>>>>> >>>>>> >>>>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych < >>>>>> corinnekrych(a)gmail.com&gt; wrote: >>>>>> > Hello Sebi, >>>>>> > >>>>>> > >>>>>> > I've done an initial work on aerogear-ios-push [swift branch], >>>>>> adding a new >>>>>> > parameter when doing the registration to pass the ag-push-id. See: >>>>>> > >>>>>> > >>>>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...c... >>>>>> > >>>>>> > This client could be tested with HelloWorld. See: >>>>>> > >>>>>> > >>>>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mob... >>>>>> > >>>>>> > What is not covered is the background app coming to foreground >>>>>> through a >>>>>> > push notification. If you look at HelloWorld: >>>>>> > >>>>>> > >>>>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e09332... >>>>>> > >>>>>> > In iOS, when we go from background to foreground we don't go >>>>>> through >>>>>> > registration API. The iOS push lib doesn't store locally (as >>>>>> opposed to >>>>>> > windows sdk for ex) the device information. So i can't really make >>>>>> another >>>>>> > call to registration API. What i'd suggest is to have a separate >>>>>> endpoint >>>>>> > for metrics instead of having it coupled with registration >>>>>> endpoint. wdyt? >>>>>> > >>>>>> > ++ >>>>>> > >>>>>> > Corinne >>>>>> > >>>>>> > On 4 May 2015 at 19:07, Sébastien Blanc <scm.blanc(a)gmail.com&gt; >>>>>> wrote: >>>>>> >> >>>>>> >> Hi Corinne ! >>>>>> >> We want to collect for both situations you described :) >>>>>> >> >>>>>> >> Envoyé de mon iPhone >>>>>> >> >>>>>> >> Le 4 mai 2015 à 17:53, Corinne Krych <corinnekrych(a)gmail.com&gt; a >>>>>> écrit : >>>>>> >> >>>>>> >> Hello Sebi, >>>>>> >> >>>>>> >> After giving it a closer look, I've got a question for you: do we >>>>>> want to >>>>>> >> collect metrics only when an app is opened via push notification >>>>>> or do we >>>>>> >> also want to collect metrics when an app is brought to foreground >>>>>> by a push >>>>>> >> notification? >>>>>> >> >>>>>> >> ++ >>>>>> >> Corinne >>>>>> >> >>>>>> >> >>>>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych(a)gmail.com&gt; >>>>>> wrote: >>>>>> >>> >>>>>> >>> Yeap >>>>>> >>> on it. >>>>>> >>> >>>>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>>> wrote: >>>>>> >>>> >>>>>> >>>> Hi, >>>>>> >>>> >>>>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been >>>>>> rebased on >>>>>> >>>> the latest master and got a lot of polishing. >>>>>> >>>> >>>>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? >>>>>> The only >>>>>> >>>> "breaking" change is the rename of the header's name that >>>>>> identifies a Push >>>>>> >>>> Notification, it's called now "aerogear-push-id" >>>>>> >>>> >>>>>> >>>> Seb >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971 >>>>>> >>>> [2] >>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540 >>>>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971 >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> _______________________________________________ >>>>>> >>>> aerogear-dev mailing list >>>>>> >>>> aerogear-dev(a)lists.jboss.org >>>>>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>> >>>>>> >>> >>>>>> >> >>>>>> >> _______________________________________________ >>>>>> >> aerogear-dev mailing list >>>>>> >> aerogear-dev(a)lists.jboss.org >>>>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >> >>>>>> >> >>>>>> >> _______________________________________________ >>>>>> >> aerogear-dev mailing list >>>>>> >> aerogear-dev(a)lists.jboss.org >>>>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> > >>>>>> > >>>>>> > >>>>>> > _______________________________________________ >>>>>> > aerogear-dev mailing list >>>>>> > aerogear-dev(a)lists.jboss.org >>>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Cheers, >>>>>> Erik Jan >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

To give a bit of background on this background to foreground issue :)) Push Cordova plugin matches Cordova life cycle by storing some information locally see: https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGP... Doing so allows you to call multiple time registration, even when an app comes back from background to foreground. you can do it because you have stored locally all the information neede for registration. But when dealing directly with native apps, the life cycle does not always goes through a registration. To sort out this issue,we can: - either store locally at the ios-push lib level instead of doing it in Cordova plugin and then call registration API on all delegate methods (even though we don't want to register but just send the metrics)

- or leave the ios-push lib without any storage and provide a separate endpoint for sending metrics or changing categories. I'd go for the second option. ++ Corinne On 5 May 2015 at 10:39, Erik Jan de Wit <edewit(a)redhat.com&gt; wrote: > I agree with this and maybe we want even more functionality moved, > because also updating the categories is strange in a 'register' > method. Say for instance you want to change the categories your > interested in a developer has to call register again? And if I > understand Corinnes mail that will currently not even work on iOS. > > For cordova I store the device info, because the lifecycle is > different, but that is okay it's an integration problem. > > So updating the installation details should be a separate method that > also contains updating the categories. That way we have a better split > between a device that registers itself with UPS and updating the > subscription data. > > > On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; > wrote: > > Hello Sebi, > > > > > > I've done an initial work on aerogear-ios-push [swift branch], adding a > new > > parameter when doing the registration to pass the ag-push-id. See: > > > > > https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...c... > > > > This client could be tested with HelloWorld. See: > > > > > https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mob... > > > > What is not covered is the background app coming to foreground through a > > push notification. If you look at HelloWorld: > > > > > https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e09332... > > > > In iOS, when we go from background to foreground we don't go through > > registration API. The iOS push lib doesn't store locally (as opposed to > > windows sdk for ex) the device information. So i can't really make > another > > call to registration API. What i'd suggest is to have a separate > endpoint > > for metrics instead of having it coupled with registration endpoint. > wdyt? > > > > ++ > > > > Corinne > > > > On 4 May 2015 at 19:07, Sébastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> > >> Hi Corinne ! > >> We want to collect for both situations you described :) > >> > >> Envoyé de mon iPhone > >> > >> Le 4 mai 2015 à 17:53, Corinne Krych <corinnekrych(a)gmail.com&gt; a écrit > : > >> > >> Hello Sebi, > >> > >> After giving it a closer look, I've got a question for you: do we want > to > >> collect metrics only when an app is opened via push notification or do > we > >> also want to collect metrics when an app is brought to foreground by a > push > >> notification? > >> > >> ++ > >> Corinne > >> > >> > >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > >>> > >>> Yeap > >>> on it. > >>> > >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > wrote: > >>>> > >>>> Hi, > >>>> > >>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased > on > >>>> the latest master and got a lot of polishing. > >>>> > >>>> Could the Client Tech Leads take a look at it [3] and review ? The > only > >>>> "breaking" change is the rename of the header's name that identifies > a Push > >>>> Notification, it's called now "aerogear-push-id" > >>>> > >>>> Seb > >>>> > >>>> > >>>> > >>>> [1] https://issues.jboss.org/browse/AGPUSH-971 > >>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540 > >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971 > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev(a)lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Cheers, > Erik Jan > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev