Hi, On Wed, Jun 17, 2015 at 4:03 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > Sooooo we have a 2.2.0 staged. Google has a ton of new functionality > rolling out for GCM. > > We think that 2.2.0 works with it mostly correctly but we are finding > some "gotchas". Notably it looks like Google is sending some ACK messages > after we register that the library is ignoring. > > We will need to support InstanceID (tl;dr; Google is enhancing > registraiton_id). Passos and I are still digesting the volumes of stuff > being rolled out from IO so we can't really give too many details right now > because we simply don't know them (And Google is still updating their docs, > fixing links, etc). > > So the question to the list is : > Do we delay 2.2.0 and include support for InstanceID and any other best > practices Google has introduced or do we release 2.2.0, document / work > around any gotchas and then prioritize GCM 3.0 support for 2.3.0? > (assuming this is related to the NPE I am seeing in [1]) I think the ultimate goal for 2.2.0 should be to to not crash like in [1]. I see three options: 1) document the work-around ([2]) and release the _existing_ 2.2.0, as is -> The fact that the work-around needs to be added to (almost) all apps, makes it an odd work-around (not saying it's a no-go) 2) delay the 2.2.0 and get full GCM 3.0 support in there -> IMO it's unknown how long that takes, and ideally our 2.2.0 AGDroid-Push should be out once we have the UPS released (early July); This also could mean a delay on our Cordova lib. 3) Update 2.2.0 to ignore the ACK sent from GCM 3.0, and get a 2.2.x (or 2.3.0) a bit later for full support on GCM 3.0 -> IMO this allows us to release UPS 1.1.0 (and AGDroid-Push) in a reasonable timeframe and moves the work-around into our library, and not onto all the app developers. My vote would be going w/ option #3, given the above reasoning and the fact that we don't use any GCM 3.0 feature atm, it sounds fairly safe (at least to me) doing the working inside of our library -Matthias [1] https://issues.jboss.org/browse/AGDROID-425 [2] https://github.com/jboss-mobile/unified-push-helloworld/commit/077bfdce89... > > > > _______________________________________________ > 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

On Wed, Jun 17, 2015 at 10:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > if #3 is possible (check&ignore the ack backed into the library) I would > go for this option as well. > The ACK is mostly ignored now. There is a log message saying that the GCM handler couldn't process it but otherwise the application is unaffected.

> On Wed, Jun 17, 2015 at 4:28 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > >> Hi, >> >> On Wed, Jun 17, 2015 at 4:03 PM, Summers Pittman <supittma(a)redhat.com&gt; >> wrote: >> >>> Sooooo we have a 2.2.0 staged. Google has a ton of new functionality >>> rolling out for GCM. >>> >>> We think that 2.2.0 works with it mostly correctly but we are finding >>> some "gotchas". Notably it looks like Google is sending some ACK messages >>> after we register that the library is ignoring. >>> >>> We will need to support InstanceID (tl;dr; Google is enhancing >>> registraiton_id). Passos and I are still digesting the volumes of stuff >>> being rolled out from IO so we can't really give too many details right now >>> because we simply don't know them (And Google is still updating their docs, >>> fixing links, etc). >>> >>> So the question to the list is : >>> Do we delay 2.2.0 and include support for InstanceID and any other >>> best practices Google has introduced or do we release 2.2.0, document / >>> work around any gotchas and then prioritize GCM 3.0 support for 2.3.0? >>> >> >> (assuming this is related to the NPE I am seeing in [1]) >> >> I think the ultimate goal for 2.2.0 should be to to not crash like in >> [1]. >> >> I see three options: >> 1) document the work-around ([2]) and release the _existing_ 2.2.0, as is >> -> The fact that the work-around needs to be added to (almost) all apps, >> makes it an odd work-around (not saying it's a no-go) >> 2) delay the 2.2.0 and get full GCM 3.0 support in there >> -> IMO it's unknown how long that takes, and ideally our 2.2.0 >> AGDroid-Push should be out once we have the UPS released (early July); This >> also could mean a delay on our Cordova lib. >> 3) Update 2.2.0 to ignore the ACK sent from GCM 3.0, and get a 2.2.x (or >> 2.3.0) a bit later for full support on GCM 3.0 >> -> IMO this allows us to release UPS 1.1.0 (and AGDroid-Push) in a >> reasonable timeframe and moves the work-around into our library, and not >> onto all the app developers. >> >> >> My vote would be going w/ option #3, given the above reasoning and the >> fact that we don't use any GCM 3.0 feature atm, it sounds fairly safe (at >> least to me) doing the working inside of our library >> >> -Matthias >> >> [1] https://issues.jboss.org/browse/AGDROID-425 >> [2] >> https://github.com/jboss-mobile/unified-push-helloworld/commit/077bfdce89... >> >> >> >>> >>> >>> >>> _______________________________________________ >>> 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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

+1 Anyway UPS add a key (in the future release) to identify the message come from UPS is also a good idea On Wed, Jun 17, 2015 at 11:42 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > On Wed, Jun 17, 2015 at 4:35 PM, Summers Pittman <supittma(a)redhat.com&gt; > wrote: > >> >> >> On Wed, Jun 17, 2015 at 10:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >> wrote: >> >>> if #3 is possible (check&ignore the ack backed into the library) I >>> would go for this option as well. >>> >> The ACK is mostly ignored now. There is a log message saying that the >> GCM handler couldn't process it but otherwise the application is >> unaffected. >> > > perfect, so #3 it is? :) > > So a bit of delay on 2.2.0, a little release note of no support of GCM 3 > and afterwards do that in 2.2.1 (or 2.3.0) ? > > > > > >> >>> On Wed, Jun 17, 2015 at 4:28 PM, Matthias Wessendorf <matzew(a)apache.org >>> > wrote: >>> >>>> Hi, >>>> >>>> On Wed, Jun 17, 2015 at 4:03 PM, Summers Pittman <supittma(a)redhat.com&gt; >>>> wrote: >>>> >>>>> Sooooo we have a 2.2.0 staged. Google has a ton of new functionality >>>>> rolling out for GCM. >>>>> >>>>> We think that 2.2.0 works with it mostly correctly but we are finding >>>>> some "gotchas". Notably it looks like Google is sending some ACK messages >>>>> after we register that the library is ignoring. >>>>> >>>>> We will need to support InstanceID (tl;dr; Google is enhancing >>>>> registraiton_id). Passos and I are still digesting the volumes of stuff >>>>> being rolled out from IO so we can't really give too many details right now >>>>> because we simply don't know them (And Google is still updating their docs, >>>>> fixing links, etc). >>>>> >>>>> So the question to the list is : >>>>> Do we delay 2.2.0 and include support for InstanceID and any other >>>>> best practices Google has introduced or do we release 2.2.0, document / >>>>> work around any gotchas and then prioritize GCM 3.0 support for 2.3.0? >>>>> >>>> >>>> (assuming this is related to the NPE I am seeing in [1]) >>>> >>>> I think the ultimate goal for 2.2.0 should be to to not crash like in >>>> [1]. >>>> >>>> I see three options: >>>> 1) document the work-around ([2]) and release the _existing_ 2.2.0, as >>>> is >>>> -> The fact that the work-around needs to be added to (almost) all >>>> apps, makes it an odd work-around (not saying it's a no-go) >>>> 2) delay the 2.2.0 and get full GCM 3.0 support in there >>>> -> IMO it's unknown how long that takes, and ideally our 2.2.0 >>>> AGDroid-Push should be out once we have the UPS released (early July); This >>>> also could mean a delay on our Cordova lib. >>>> 3) Update 2.2.0 to ignore the ACK sent from GCM 3.0, and get a 2.2.x >>>> (or 2.3.0) a bit later for full support on GCM 3.0 >>>> -> IMO this allows us to release UPS 1.1.0 (and AGDroid-Push) in a >>>> reasonable timeframe and moves the work-around into our library, and not >>>> onto all the app developers. >>>> >>>> >>>> My vote would be going w/ option #3, given the above reasoning and the >>>> fact that we don't use any GCM 3.0 feature atm, it sounds fairly safe (at >>>> least to me) doing the working inside of our library >>>> >>>> -Matthias >>>> >>>> [1] https://issues.jboss.org/browse/AGDROID-425 >>>> [2] >>>> https://github.com/jboss-mobile/unified-push-helloworld/commit/077bfdce89... >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> _______________________________________________ >> 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 > -- -- Passos _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi, On Wed, Jun 17, 2015 at 4:03 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > Sooooo we have a 2.2.0 staged. Google has a ton of new functionality > rolling out for GCM. > > We think that 2.2.0 works with it mostly correctly but we are finding > some "gotchas". Notably it looks like Google is sending some ACK messages > after we register that the library is ignoring. > > We will need to support InstanceID (tl;dr; Google is enhancing > registraiton_id). Passos and I are still digesting the volumes of stuff > being rolled out from IO so we can't really give too many details right now > because we simply don't know them (And Google is still updating their docs, > fixing links, etc). > > So the question to the list is : > Do we delay 2.2.0 and include support for InstanceID and any other best > practices Google has introduced or do we release 2.2.0, document / work > around any gotchas and then prioritize GCM 3.0 support for 2.3.0? > (assuming this is related to the NPE I am seeing in [1]) I think the ultimate goal for 2.2.0 should be to to not crash like in [1]. I see three options: 1) document the work-around ([2]) and release the _existing_ 2.2.0, as is -> The fact that the work-around needs to be added to (almost) all apps, makes it an odd work-around (not saying it's a no-go) 2) delay the 2.2.0 and get full GCM 3.0 support in there -> IMO it's unknown how long that takes, and ideally our 2.2.0 AGDroid-Push should be out once we have the UPS released (early July); This also could mean a delay on our Cordova lib. 3) Update 2.2.0 to ignore the ACK sent from GCM 3.0, and get a 2.2.x (or 2.3.0) a bit later for full support on GCM 3.0 -> IMO this allows us to release UPS 1.1.0 (and AGDroid-Push) in a reasonable timeframe and moves the work-around into our library, and not onto all the app developers. My vote would be going w/ option #3, given the above reasoning and the fact that we don't use any GCM 3.0 feature atm, it sounds fairly safe (at least to me) doing the working inside of our library -Matthias [1] https://issues.jboss.org/browse/AGDROID-425 [2] https://github.com/jboss-mobile/unified-push-helloworld/commit/077bfdce89... > > > > _______________________________________________ > 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