[aerogear-dev] Mozilla API Alignment for SimplePush

[Bruno Oliveira]

+1

Lucas Holmquist wrote:
> +1
> On Aug 28, 2013, at 10:39 AM, Kris Borchers <kborcher at redhat.com
> <mailto:kborcher at redhat.com>> wrote:
> 
>>
>>
>> On Aug 28, 2013, at 9:36, Daniel Bevenius <daniel.bevenius at gmail.com
>> <mailto:daniel.bevenius at gmail.com>> wrote:
>>
>>> +1 Sounds good and I've moved the following task into SimplePush
>>> 0.9.0 for the clean up of channelIds:
>>> https://issues.jboss.org/browse/AGPUSH-204
>>
>> Perfect, thanks!
>>>
>>>
>>> On 28 August 2013 16:32, Summers Pittman <supittma at redhat.com
>>> <mailto:supittma at redhat.com>> wrote:
>>>
>>>     On 08/28/2013 10:12 AM, Kris Borchers wrote:
>>>>     As I work more and more toward aligning with the API spec laid
>>>>     out by Mozilla for SimplePush, I find myself needing to make a
>>>>     major change to the way we have implemented channel
>>>>     registrations. Basically what I have found is that our storage
>>>>     and reuse of channels between app restart/refresh, though meant
>>>>     to be an improvement to performance, is causing more issues than
>>>>     it's solving.
>>>>
>>>>     The Proposal
>>>>     I would like to only persist the user agent id (UAID) in storage
>>>>     and only keep the channel registrations in memory while the app
>>>>     is running. Each time the app starts up, the workflow would be:
>>>>
>>>>       * First Start
>>>>          1. Client Hello => Server
>>>>          2. Server Ack => Client
>>>>          3. Client 1 or more channel registrations => Server
>>>>          4. Server stores channel and sends pushEndpoint => Client
>>>>          5. Client registers endpont => App Server or UP Server
>>>>          6. Push messages abound
>>>>       * Restart / Refresh
>>>>          1. Client Hello => Server
>>>>          2. Server recognizes UAID and since no channels were
>>>>             included in Hello, all existing channels are removed as
>>>>             per the spec and sends Ack => Client
>>>>          3. Client 1 or more channel registrations => Server
>>>>          4. Server stores channel and sends pushEndpoint => Client
>>>>          5. Client registers endpont => App Server or UP Server
>>>>          6. Push messages abound
>>>>
>>>>
>>>>     The only possible downside I see here is there will be slightly
>>>>     more chatter over the network since the registrations will
>>>>     happen every time the app loads. There should be no performance
>>>>     decrease and may see a performance boost since we will be
>>>>     eliminating a number of synchronous calls into localStorage. The
>>>>     main benefit is that this will allow us to almost completely
>>>>     synchronize our API with Mozilla's which would then allow for
>>>>     immediate use of one of our apps as a web app and Firefox OS app
>>>>     with NO modifications.
>>>>
>>>>     Any thoughts?
>>>     Sounds good.  While not 100% related rerunning registration on
>>>     app load is something Google suggests for GCM.
>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     aerogear-dev mailing list
>>>>     aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>>>>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>     _______________________________________________
>>>     aerogear-dev mailing list
>>>     aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org <mailto: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

-- 
abstractj


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130830/993ca07c/attachment.bin