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

Lucas Holmquist lholmqui at redhat.com
Wed Jul 10 08:14:32 EDT 2013


On Jul 10, 2013, at 8:00 AM, Matthias Wessendorf <matzew at apache.org> wrote:

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


i think having this makes sense,  the only way to do that now is to loop and send individual requests


> -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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130710/76257da5/attachment.html 


More information about the aerogear-dev mailing list