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?

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

+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

On 28 August 2013 16:32, Summers Pittman <supittma(a)redhat.com&gt; 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 >> Client Hello => Server >> Server Ack => Client >> Client 1 or more channel registrations => Server >> Server stores channel and sends pushEndpoint => Client >> Client registers endpont => App Server or UP Server >> Push messages abound >> Restart / Refresh >> Client Hello => Server >> Server recognizes UAID and since no channels were included in Hello, all existing channels are removed as per the spec and sends Ack => Client >> Client 1 or more channel registrations => Server >> Server stores channel and sends pushEndpoint => Client >> Client registers endpont => App Server or UP Server >> 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(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 On Aug 28, 2013, at 10:39 AM, Kris Borchers <kborcher(a)redhat.com <mailto:kborcher@redhat.com>> wrote: > > > On Aug 28, 2013, at 9:36, Daniel Bevenius <daniel.bevenius(a)gmail.com > <mailto:daniel.bevenius@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(a)redhat.com >> <mailto:supittma@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(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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