That all seems sane to me. +1 On Jul 9, 2013, at 3:57 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Hello! > > right now the iOS variant does _only_ support upload of an "Development SSL Certificate" (see [1]). I'd like to add support for an "Production SSL Certificate" to the iOS Variant model class. > > Besides the second certificate, the model class _should_ have a field to reflect the status (is production or not -> isProduction()), so that only one certificate is ACTIVE. Internally the "Sender API" would connect against the differen Apple servers (prod. verus dev), based on the value of the isProduction() method. > > Exposing "production" (or "development") on the Sender API would be really ugly. With the above said, the Sender-API remains stable. > > The value of "isProduction" would be updateable on the AdminUI (and the underlying RESTful endpoints). > > -Matthias > > [1] https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... > > > -- > 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 Jul 9, 2013, at 6:47 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: Sounds good. but i wonder if there would be a case where both could be active at the same time. for example, some company has an app that is in production, now they need to make some modifications to it and want to make sure that they didn't break their push notifications, so they want to send some push notifications to the development version since they have separate development devices. probably an edge case Hmmm. I'm not sure how edge that is. Seems like the appropriate development model to be able to test a change while keeping the production version running. I think this is a good case for being able to have both active and would require the ability to distinguish between the two in the Sender API. On Jul 9, 2013, at 7:25 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: That all seems sane to me. +1 On Jul 9, 2013, at 3:57 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: Hello! right now the iOS variant does _only_ support upload of an "Development SSL Certificate" (see [1]). I'd like to add support for an "Production SSL Certificate" to the iOS Variant model class. Besides the second certificate, the model class _should_ have a field to reflect the status (is production or not -> isProduction()), so that only one certificate is ACTIVE. Internally the "Sender API" would connect against the differen Apple servers (prod. verus dev), based on the value of the isProduction() method. Exposing "production" (or "development") on the Sender API would be really ugly. With the above said, the Sender-API remains stable. The value of "isProduction" would be updateable on the AdminUI (and the underlying RESTful endpoints). -Matthias [1] https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... -- 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jul 9, 2013, at 6:56 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: They could have a "test" variant :) I'd hate to expose something like "prod/dev" to the sender, especially since that is ONLY iOS :) I guess a test variant would do the job. I'm good either way on that. Probably another thing that would need clear documentation.

However, on the long run... you can have a TEST PushEE server + a "production" one (AGPUSH-113) On Tue, Jul 9, 2013 at 1:50 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jul 9, 2013, at 6:47 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > Sounds good. > > but i wonder if there would be a case where both could be active at the > same time. > > for example, some company has an app that is in production, now they > need to make some modifications to it and want to make sure that they > didn't break their push notifications, so they want to send some push > notifications to the development version since they have separate > development devices. > > probably an edge case > > > Hmmm. I'm not sure how edge that is. Seems like the appropriate > development model to be able to test a change while keeping the production > version running. I think this is a good case for being able to have both > active and would require the ability to distinguish between the two in the > Sender API. > > > > On Jul 9, 2013, at 7:25 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > That all seems sane to me. +1 > > On Jul 9, 2013, at 3:57 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > Hello! > > right now the iOS variant does _only_ support upload of an "Development > SSL Certificate" (see [1]). I'd like to add support for an "Production SSL > Certificate" to the iOS Variant model class. > > Besides the second certificate, the model class _should_ have a field to > reflect the status (is production or not -> isProduction()), so that only > one certificate is ACTIVE. Internally the "Sender API" would connect > against the differen Apple servers (prod. verus dev), based on the value of > the isProduction() method. > > Exposing "production" (or "development") on the Sender API would be > really ugly. With the above said, the Sender-API remains stable. > > The value of "isProduction" would be updateable on the AdminUI (and the > underlying RESTful endpoints). > > -Matthias > > [1] > https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... > > > -- > 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 > > > > _______________________________________________ > 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 Jul 9, 2013, at 7:09 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Tue, Jul 9, 2013 at 2:04 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jul 9, 2013, at 6:56 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > They could have a "test" variant :) I'd hate to expose something like > "prod/dev" to the sender, especially since that is ONLY iOS :) > > > I guess a test variant would do the job. I'm good either way on that. > Probably another thing that would need clear documentation. > I guess having a "staging" : "production" (or "development") is also not a bad thing (helps, perhaps, already for AGPUSH-113. What would the default be ? My current feeling is that "production" is always used, unless "staging" : "development" is included on the Sender API ? +1 for production default

-Matthias > > > However, on the long run... you can have a TEST PushEE server + a > "production" one (AGPUSH-113) > > > On Tue, Jul 9, 2013 at 1:50 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Jul 9, 2013, at 6:47 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >> Sounds good. >> >> but i wonder if there would be a case where both could be active at the >> same time. >> >> for example, some company has an app that is in production, now they >> need to make some modifications to it and want to make sure that they >> didn't break their push notifications, so they want to send some push >> notifications to the development version since they have separate >> development devices. >> >> probably an edge case >> >> >> Hmmm. I'm not sure how edge that is. Seems like the appropriate >> development model to be able to test a change while keeping the production >> version running. I think this is a good case for being able to have both >> active and would require the ability to distinguish between the two in the >> Sender API. >> >> >> >> On Jul 9, 2013, at 7:25 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >> That all seems sane to me. +1 >> >> On Jul 9, 2013, at 3:57 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> Hello! >> >> right now the iOS variant does _only_ support upload of an "Development >> SSL Certificate" (see [1]). I'd like to add support for an "Production SSL >> Certificate" to the iOS Variant model class. >> >> Besides the second certificate, the model class _should_ have a field to >> reflect the status (is production or not -> isProduction()), so that only >> one certificate is ACTIVE. Internally the "Sender API" would connect >> against the differen Apple servers (prod. verus dev), based on the value of >> the isProduction() method. >> >> Exposing "production" (or "development") on the Sender API would be >> really ugly. With the above said, the Sender-API remains stable. >> >> The value of "isProduction" would be updateable on the AdminUI (and the >> underlying RESTful endpoints). >> >> -Matthias >> >> [1] >> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >> >> >> -- >> 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 >> >> >> >> _______________________________________________ >> 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

On Tue, Jul 9, 2013 at 2:21 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > > On Tue, Jul 9, 2013 at 2:14 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Jul 9, 2013, at 7:09 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> >> >> >> On Tue, Jul 9, 2013 at 2:04 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >>> >>> On Jul 9, 2013, at 6:56 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> They could have a "test" variant :) I'd hate to expose something like >>> "prod/dev" to the sender, especially since that is ONLY iOS :) >>> >>> >>> I guess a test variant would do the job. I'm good either way on that. >>> Probably another thing that would need clear documentation. >>> >> >> I guess having a "staging" : "production" (or "development") is also not >> a bad thing (helps, perhaps, already for AGPUSH-113. >> >> >> What would the default be ? My current feeling is that "production" is >> always used, unless "staging" : "development" is included on the Sender API >> ? >> >> >> +1 for production default >> > > In that case, no "isProd()" is needed :-) > I mean generally, if both can be "active" (we would just check if cert/passphrase is present) > > > > >> >> >> >> -Matthias >> >> >> >> >>> >>> >>> However, on the long run... you can have a TEST PushEE server + a >>> "production" one (AGPUSH-113) >>> >>> >>> On Tue, Jul 9, 2013 at 1:50 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>>> >>>> On Jul 9, 2013, at 6:47 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; >>>> wrote: >>>> >>>> Sounds good. >>>> >>>> but i wonder if there would be a case where both could be active at >>>> the same time. >>>> >>>> for example, some company has an app that is in production, now they >>>> need to make some modifications to it and want to make sure that they >>>> didn't break their push notifications, so they want to send some push >>>> notifications to the development version since they have separate >>>> development devices. >>>> >>>> probably an edge case >>>> >>>> >>>> Hmmm. I'm not sure how edge that is. Seems like the appropriate >>>> development model to be able to test a change while keeping the production >>>> version running. I think this is a good case for being able to have both >>>> active and would require the ability to distinguish between the two in the >>>> Sender API. >>>> >>>> >>>> >>>> On Jul 9, 2013, at 7:25 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>> >>>> That all seems sane to me. +1 >>>> >>>> On Jul 9, 2013, at 3:57 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>> wrote: >>>> >>>> Hello! >>>> >>>> right now the iOS variant does _only_ support upload of an >>>> "Development SSL Certificate" (see [1]). I'd like to add support for an >>>> "Production SSL Certificate" to the iOS Variant model class. >>>> >>>> Besides the second certificate, the model class _should_ have a field >>>> to reflect the status (is production or not -> isProduction()), so that >>>> only one certificate is ACTIVE. Internally the "Sender API" would connect >>>> against the differen Apple servers (prod. verus dev), based on the value of >>>> the isProduction() method. >>>> >>>> Exposing "production" (or "development") on the Sender API would be >>>> really ugly. With the above said, the Sender-API remains stable. >>>> >>>> The value of "isProduction" would be updateable on the AdminUI (and >>>> the underlying RESTful endpoints). >>>> >>>> -Matthias >>>> >>>> [1] >>>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>>> >>>> >>>> -- >>>> 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 >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

BTW.... when creating the iOS varian.... developmentCertificate/Passphrase and productionCertificate/Passphrase are the new Formular Values....... (needs to be updated) -M On Tue, Jul 9, 2013 at 6:41 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: Hi, I pushed an early version of it to [1]. It's a branch, not (yet) a PR. Basically here is a how the payloads MIGHT look like: Broadcast Payload: { "alert":"HELLO!", "sound":"default", "staging":"development", "badge":7, "simple-push":"version=123", "someKey":"some value", "anotherCustomKey":"some other value" } Selective Send Payload: { "alias" : [&quot;user(a)account.com&quot;, &quot;someone(a)aerogear.org&quot;, ....], "deviceType" : ["iPad", "AndroidTablet"], "staging":"development", "message": { "alert":"HELLO!", "sound":"default", "badge":7, "someKey":"some value", "anotherCustomKey":"some other value" }, "simple-push": { "SomeCategory":"version=123", "anotherCategory":"version=456" } } Note: if the "staging" is NOT present, the PRODUCTION cert. (if present) will be used. If no cert is present ..... a WARNING is logged... Also,..... only on iOS.... -Matthias [1] https://github.com/aerogear/aerogear-unified-push-server/tree/ProdCerts On Tue, Jul 9, 2013 at 2:40 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: On Tue, Jul 9, 2013 at 2:21 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: On Tue, Jul 9, 2013 at 2:14 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Jul 9, 2013, at 7:09 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Tue, Jul 9, 2013 at 2:04 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Jul 9, 2013, at 6:56 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: They could have a "test" variant :) I'd hate to expose something like "prod/dev" to the sender, especially since that is ONLY iOS :) I guess a test variant would do the job. I'm good either way on that. Probably another thing that would need clear documentation. I guess having a "staging

I'd say make STAGING default and enforce developers to upload the certificate again if she wants to use the same certificate.

Or maybe an option which says cert-prod.blah - staging/prod. From my understanding if it defaults to production, we can motivate people to mistakes in production with a valid certificate. Developers should be aware of test it before push anything to production.

Is just my perspective. Matthias Wessendorf wrote: > BTW.... when creating the iOS varian.... > > > developmentCertificate/Passphrase and productionCertificate/Passphrase > are the new Formular Values....... (needs to be updated) > > > -M > > > On Tue, Jul 9, 2013 at 6:41 PM, Matthias Wessendorf <matzew(a)apache.org > <mailto:matzew@apache.org>> wrote: > > Hi, > > I pushed an early version of it to [1]. It's a branch, not (yet) a PR. > > Basically here is a how the payloads MIGHT look like: > > Broadcast Payload: > { > "alert":"HELLO!", > "sound":"default", > "staging":"development", > "badge":7, > "simple-push":"version=123", > "someKey":"some value", > "anotherCustomKey":"some other value" > } > > Selective Send Payload: > { > "alias" : [&quot;user(a)account.com <mailto:user@account.com>", > &quot;someone(a)aerogear.org <mailto:someone@aerogear.org>", ....], > "deviceType" : ["iPad", "AndroidTablet"], > "staging":"development", > "message": { > "alert":"HELLO!", > "sound":"default", > "badge":7, > "someKey":"some value", > "anotherCustomKey":"some other value" > }, > "simple-push": { > "SomeCategory":"version=123", > "anotherCategory":"version=456" > } > } > > Note: if the "staging" is NOT present, the PRODUCTION cert. (if > present) will be used. If no cert is present ..... a WARNING is > logged... > > Also,..... only on iOS.... > > > -Matthias > > [1] > https://github.com/aerogear/aerogear-unified-push-server/tree/ProdCerts > > > > > On Tue, Jul 9, 2013 at 2:40 PM, Matthias Wessendorf > <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > > > > > On Tue, Jul 9, 2013 at 2:21 PM, Matthias Wessendorf > <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > > > > > On Tue, Jul 9, 2013 at 2:14 PM, Kris Borchers > <kris(a)redhat.com <mailto:kris@redhat.com>> wrote: > > > On Jul 9, 2013, at 7:09 AM, Matthias Wessendorf > <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > >> >> >> >> On Tue, Jul 9, 2013 at 2:04 PM, Kris Borchers >> <kris(a)redhat.com <mailto:kris@redhat.com>> wrote: >> >> >> On Jul 9, 2013, at 6:56 AM, Matthias Wessendorf >> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >> >>> They could have a "test" variant :) I'd hate to >>> expose something like "prod/dev" to the sender, >>> especially since that is ONLY iOS :) >> >> I guess a test variant would do the job. I'm good >> either way on that. Probably another thing that >> would need clear documentation. >> >> >> I guess having a "staging" : "production" (or >> "development") is also not a bad thing (helps, >> perhaps, already for AGPUSH-113. >> >> >> What would the default be ? My current feeling is that >> "production" is always used, unless "staging" : >> "development" is included on the Sender API ? > > +1 for production default > > > In that case, no "isProd()" is needed :-) > > > I mean generally, if both can be "active" (we would just check > if cert/passphrase is present) > > > > >> >> >> -Matthias >> >> >> >>> >>> However, on the long run... you can have a TEST >>> PushEE server + a "production" one (AGPUSH-113) >>> >>> >>> On Tue, Jul 9, 2013 at 1:50 PM, Kris Borchers >>> <kris(a)redhat.com <mailto:kris@redhat.com>> wrote: >>> >>> >>> On Jul 9, 2013, at 6:47 AM, Lucas Holmquist >>> <lholmqui(a)redhat.com >>> <mailto:lholmqui@redhat.com>> wrote: >>> >>>> Sounds good. >>>> >>>> but i wonder if there would be a case where >>>> both could be active at the same time. >>>> >>>> for example, some company has an app that >>>> is in production, now they need to make >>>> some modifications to it and want to make >>>> sure that they didn't break their push >>>> notifications, so they want to send some >>>> push notifications to the development >>>> version since they have separate development >>>> devices. >>>> >>>> probably an edge case >>> >>> Hmmm. I'm not sure how edge that is. Seems >>> like the appropriate development model to be >>> able to test a change while keeping the >>> production version running. I think this is a >>> good case for being able to have both active >>> and would require the ability to distinguish >>> between the two in the Sender API. >>> >>>> >>>> >>>> On Jul 9, 2013, at 7:25 AM, Kris Borchers >>>> <kris(a)redhat.com <mailto:kris@redhat.com>> >>>> wrote: >>>> >>>>> That all seems sane to me. +1 >>>>> >>>>> On Jul 9, 2013, at 3:57 AM, Matthias >>>>> Wessendorf <matzew(a)apache.org >>>>> <mailto:matzew@apache.org>> wrote: >>>>> >>>>>> Hello! >>>>>> >>>>>> right now the iOS variant does _only_ >>>>>> support upload of an "Development SSL >>>>>> Certificate" (see [1]). I'd like to add >>>>>> support for an "Production SSL >>>>>> Certificate" to the iOS Variant model class. >>>>>> >>>>>> Besides the second certificate, the model >>>>>> class _should_ have a field to reflect the >>>>>> status (is production or not -> >>>>>> isProduction()), so that only one >>>>>> certificate is ACTIVE. Internally the >>>>>> "Sender API" would connect against the >>>>>> differen Apple servers (prod. verus dev), >>>>>> based on the value of the isProduction() >>>>>> method. >>>>>> >>>>>> Exposing "production" (or "development") >>>>>> on the Sender API would be really ugly. >>>>>> With the above said, the Sender-API >>>>>> remains stable. >>>>>> >>>>>> The value of "isProduction" would be >>>>>> updateable on the AdminUI (and the >>>>>> underlying RESTful endpoints). >>>>>> >>>>>> -Matthias >>>>>> >>>>>> [1] >>>>>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>>> <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 >>> >>> >>> >>> >>> -- >>> 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 >>> <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 >> >> >> >> >> -- >> 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 >> <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 > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > > > -- > 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 -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Jul 9, 2013 at 1:50 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jul 9, 2013, at 6:47 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > Sounds good. > > but i wonder if there would be a case where both could be active at the > same time. > > for example, some company has an app that is in production, now they > need to make some modifications to it and want to make sure that they > didn't break their push notifications, so they want to send some push > notifications to the development version since they have separate > development devices. > > probably an edge case > > > Hmmm. I'm not sure how edge that is. Seems like the appropriate > development model to be able to test a change while keeping the production > version running. I think this is a good case for being able to have both > active and would require the ability to distinguish between the two in the > Sender API. > Kris/Luke as mentioned in [1] the device token on the Production Profile / environment is different. If one variant has both options (test/prod), I think that there may be some tokens left over (Apple's feedback service would not catch that - since it only looks for "invalid" tokens, on the actual profile (invalid means: User disabled push, on the device - or deleted app). Having a "test" variant allows the user to have the test tokens on a different variant, and not being mixed. What's your thoughts on that?

-Matthias [1] http://lists.jboss.org/pipermail/aerogear-dev/2013-July/003879.html > > > > On Jul 9, 2013, at 7:25 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > That all seems sane to me. +1 > > On Jul 9, 2013, at 3:57 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > Hello! > > right now the iOS variant does _only_ support upload of an "Development > SSL Certificate" (see [1]). I'd like to add support for an "Production SSL > Certificate" to the iOS Variant model class. > > Besides the second certificate, the model class _should_ have a field to > reflect the status (is production or not -> isProduction()), so that only > one certificate is ACTIVE. Internally the "Sender API" would connect > against the differen Apple servers (prod. verus dev), based on the value of > the isProduction() method. > > Exposing "production" (or "development") on the Sender API would be > really ugly. With the above said, the Sender-API remains stable. > > The value of "isProduction" would be updateable on the AdminUI (and the > underlying RESTful endpoints). > > -Matthias > > [1] > https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... > > > -- > 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 > > > > _______________________________________________ > 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

On Jul 11, 2013, at 7:15 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Thu, Jul 11, 2013 at 1:12 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > > On Tue, Jul 9, 2013 at 1:50 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Jul 9, 2013, at 6:47 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >> Sounds good. >> >> but i wonder if there would be a case where both could be active at the >> same time. >> >> for example, some company has an app that is in production, now they >> need to make some modifications to it and want to make sure that they >> didn't break their push notifications, so they want to send some push >> notifications to the development version since they have separate >> development devices. >> >> probably an edge case >> >> >> Hmmm. I'm not sure how edge that is. Seems like the appropriate >> development model to be able to test a change while keeping the production >> version running. I think this is a good case for being able to have both >> active and would require the ability to distinguish between the two in the >> Sender API. >> > > > Kris/Luke > > as mentioned in [1] the device token on the Production Profile / > environment is different. If one variant has both options (test/prod), I > think that there may be some tokens left over (Apple's feedback service > would not catch that - since it only looks for "invalid" tokens, on the > actual profile (invalid means: User disabled push, on the device - or > deleted app). > > Having a "test" variant allows the user to have the test tokens on a > different variant, and not being mixed. What's your thoughts on that? > One more thing, it is kinda odd that (by switching Profiles) the iOS app becomes a different token.

I guess just allowing one cert/passphrase per Variant does make more sense... A boolean flag would indicate if the app is production or not … +1 -Matthias > > > -Matthias > > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2013-July/003879.html > > > > >> >> >> >> On Jul 9, 2013, at 7:25 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >> That all seems sane to me. +1 >> >> On Jul 9, 2013, at 3:57 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> Hello! >> >> right now the iOS variant does _only_ support upload of an "Development >> SSL Certificate" (see [1]). I'd like to add support for an "Production SSL >> Certificate" to the iOS Variant model class. >> >> Besides the second certificate, the model class _should_ have a field to >> reflect the status (is production or not -> isProduction()), so that only >> one certificate is ACTIVE. Internally the "Sender API" would connect >> against the differen Apple servers (prod. verus dev), based on the value of >> the isProduction() method. >> >> Exposing "production" (or "development") on the Sender API would be >> really ugly. With the above said, the Sender-API remains stable. >> >> The value of "isProduction" would be updateable on the AdminUI (and the >> underlying RESTful endpoints). >> >> -Matthias >> >> [1] >> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >> >> >> -- >> 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 >> >> >> >> _______________________________________________ >> 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 > -- 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