On Tue, Jul 9, 2013 at 2:14 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Jul 9, 2013, at 7:09 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, Jul 9, 2013 at 2:04 PM, Kris Borchers <kris(a)redhat.com> wrote:
>
> On Jul 9, 2013, at 6:56 AM, Matthias Wessendorf <matzew(a)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 :-)
-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> wrote:
>
>>
>> On Jul 9, 2013, at 6:47 AM, Lucas Holmquist <lholmqui(a)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> wrote:
>>
>> That all seems sane to me. +1
>>
>> On Jul 9, 2013, at 3:57 AM, Matthias Wessendorf <matzew(a)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
>>
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