On Wed, Jul 10, 2013 at 2:38 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
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
Ok, but that's not the problem of the Java-Client-Sender, nor the Server.
However, there are several options, the "backend" can "receive" these
bits.
One would be introducing an API, that returns variantID,description and
name for all variants of a given PushApplication. But that's a different
thread, IMO.
>
>
>
>
>
>
>>
>>
>>> 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
>
_______________________________________________
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