On Tue, Oct 28, 2014 at 3:53 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
On Tue, Oct 28, 2014 at 3:42 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>
>
> On Tue, Oct 28, 2014 at 3:39 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
> wrote:
>
>> +1
>> Since we are talking about the sender part maybe in the config we could
>> add more than 1 config , (think of multitenant apps using different UPS
>> configs)
>>
>> [
>> {
>> "name":"Customer1App",
>> "url":"url",
>> "PushId":"shht",
>> "MasterSecret":"shht"
>> },
>> {
>> "name":"Customer2App",
>> "url":"url",
>> "PushId":"shht",
>> "MasterSecret":"shht"
>> },
>> ...
>> ]
>> We could even pass a "default" flag for one of the config items.
>>
>> wdyt ?
>>
>
> uh, not sure. Can you explain, why I want a global config?
>
> I'd rather have something, per app
>
I think, that often, one single Backend will have to deal with different
Push Applications. Imagine a company using UPS to deploy its own
UrbanAirship/Parse stuff , having a plenty of users or a custom mBaaS
solution.
hrm, not sure.
How would you than trigger, or glue the different settings? and when do you
know which one is used ?
I'd rather perfer "one.json" and "two.json" being on the
classpath, and
than have the Sender 'reference' to it:
somesender = new Sender(new file("one.json"));
// somewhere lese in the app:
someOtherSender = new Sender(new file("two.json"));
Or even, to be able to switch easily from a test/dev/user acceptance
environement.
>
>
>>
>>
>>
>>
>> On Tue, Oct 28, 2014 at 3:31 PM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> on the Cordova 1.0.2 push plugin, we now have the handy option to
>>> configure the server settings in an external JSON file.
>>>
>>>
>>> A few days we spoke about this for the senders as well. Now, after a
>>> few days, I am wondering, does it make sense to have an external
>>> configuration file for our node.js/java senders ?
>>>
>>> -Matthias
>>>
>>> --
>>> 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