On Wed, Jul 10, 2013 at 2:36 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
On Wed, Jul 10, 2013 at 2:26 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
>
>
>
> On Wed, Jul 10, 2013 at 2:00 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>
>>
>>
>>
>> On Wed, Jul 10, 2013 at 1:44 PM, Sebastien Blanc
<scm.blanc(a)gmail.com>wrote:
>>
>>>
>>>
>>>
>>> On Wed, Jul 10, 2013 at 12:06 PM, Matthias Wessendorf <
>>> matzew(a)apache.org> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jul 10, 2013 at 12:00 PM, Sebastien Blanc
<scm.blanc(a)gmail.com
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 10, 2013 at 11:51 AM, Matthias Wessendorf <
>>>>> matzew(a)apache.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 10, 2013 at 11:47 AM, Sebastien Blanc <
>>>>>> scm.blanc(a)gmail.com> wrote:
>>>>>>
>>>>>>> You mean adding this to the Java Sender API ?
>>>>>>>
>>>>>>
>>>>>> I thought adding it to the SERVER, but yeah the Java Client needs
to
>>>>>> reflect that as well :-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I'm okay with it but we just have to keep in mind that
the backend
>>>>>>> app using the sender should be totally agnostic to who it
send messages to
>>>>>>> (And the backend app should not know the variant ids, only
the push app id,
>>>>>>> so .... ) maybe using another terminology ?
>>>>>>>
>>>>>>
>>>>>> Not sure I agree.
>>>>>>
>>>>> Sure it is not about agreeing or disagreeing here ;) but we should
>>>>> discuss this. Maybe the backend could query the push server to
retrive the
>>>>> available variants ?
>>>>>
>>>>
>>>>
>>>> Interesting point - but that's a different discussion :)
>>>>
>>>> Not sure I want the business backend to query the PushServer, asking
>>>> for variants .... ( also a right issue).
>>>>
>>>> Even so... if that hook would be added to the server...., we would
>>>> still need the "variants" : {arrayOfVariantIDs} on the REST
>>>> endpoint, and a reflection of that, on the JAva Sender, right ?
>>>>
>>>
>>> Right, deciding to send to "premium" or "Free" variants
really relies
>>> on business logic so at the end , the backend end must be aware of it ;) .
>>>
>>
>> Yes, not very surprisingly a simple form, on the "business backend"
>> cloud do that :)
>>
>>
>> ----Send promotion code--------
>> List of "app IDs": [text field accepting variantIDs];
>>
>> [SEND button]
>>
>>
>> Or, it may be even coded into the app, or.... the server could have a
>> "API" to ask for "available" variants for PushApp XYZ (but
that's a
>> different thing).
>>
>>
>> Back to the original question: So if we want to notify a selected list
>> of variants, the Server needs to understand that. I think having
"variants"
>> : {arrayOfVariantIDs} on the payload seems reasonable.
>>
> Yeah to stick to the original question, this seems the right way to go
> (but keeping in mind how we would "translate" that for the Sender)
>
"translate" ? Do you mean how the backend get's the IDs? or what ?
yes exactly
>
>
>> Once the sever accepts that, the Java Client API should support that
>> as well (e.g. variantIDs(varargs))
>>
>>
>> -Matthias
>>
>>
>>
>>
>>
>>> The thing is where to put that (on the sender ? BE directly accessing
>>> the PSUH endpoint ? ) but for sure it is a must have (as we don't want
to
>>> the push server to hold any business logic)
>>>
>>>
>>>>
>>>> -Matthias
>>>>
>>>>
>>>>>
>>>>>> A marketing backend could have a special "coupon" for
Tablet users.
>>>>>> Again, it's up the business logic :-)
>>>>>>
>>>>>> -Matthias
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jul 10, 2013 at 11:34 AM, Matthias Wessendorf <
>>>>>>> matzew(a)apache.org> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> For adding support to "select" some variants
(e.g. "Android Tablet
>>>>>>>> optimized variant" _and_ "iPad mini
variant" _and_ "SimplePush variant"),
>>>>>>>> when sending messages, I'd like to update the
Selective Sender API and add
>>>>>>>> a new field:
>>>>>>>>
>>>>>>>> "variants" : {arrayOfVariantIDs}
>>>>>>>>
>>>>>>>>
>>>>>>>> IMO the broadcast should NOT have such an option, since
it
>>>>>>>> broadcasts to everything. At least that's my
understanding of it.
>>>>>>>>
>>>>>>>> Any thoughts?
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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