Re: [aerogear-dev] Sending messages to a (few) specific variant(s)

On Wed, Jul 10, 2013 at 1:44 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > > > > On Wed, Jul 10, 2013 at 12:06 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > >> >> >> >> On Wed, Jul 10, 2013 at 12:00 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: >> >>> >>> >>> >>> On Wed, Jul 10, 2013 at 11:51 AM, Matthias Wessendorf < >>> matzew(a)apache.org&gt; 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.

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&gt; 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