[aerogear-dev] GCM 3.0 and Instance ID

Wed Jun 17 11:04:03 EDT 2015

we can do that now, and infact the push-message-id (we introduced for
analyics) is already that kinda identifier

-M

On Wed, Jun 17, 2015 at 4:45 PM, Daniel Passos <dpassos at redhat.com> wrote:

> +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 at apache.org>
> wrote:
>
>>
>>
>> On Wed, Jun 17, 2015 at 4:35 PM, Summers Pittman <supittma at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Jun 17, 2015 at 10:32 AM, Sebastien Blanc <scm.blanc at gmail.com>
>>> 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 at apache.org
>>>> > wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Wed, Jun 17, 2015 at 4:03 PM, Summers Pittman <supittma at redhat.com>
>>>>> 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/077bfdce8980f86fde1662b490139573792c82fc
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150617/de57d148/attachment.html 