<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 27, 2013 at 9:49 AM, Sebastien Blanc <span dir="ltr"><<a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="im"><div>On Fri, Sep 27, 2013 at 9:12 AM, Apostolos Emmanouilidis <span dir="ltr"><<a href="mailto:aemmanou@redhat.com" target="_blank">aemmanou@redhat.com</a>></span> wrote:<br>
</div></div><div class="gmail_extra">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><u></u>
<div>
I received some feedback for the aerogear-unifiedpush-server. <br>
<br>
The case is:<br>
<br>
Company X would like to create a personalized push notifications campaign for Y hundred thousands customers/clients. Personalized means that each client/device should receive a unique message. The messages are automatically produced from rules defined in a CRM system, but this is something which doesn't affect our implementation.<br>
<br>
Currently, our selective send method is able to send one message to a selected list of clients. In cases like the above one, this translates into Y hundred thousands calls of the aerogear-unifiedpush-server selective send method. The question is whether we could change the signature of the selective send method and allow to pass an array of messages or not. <br>
<br>
In my understanding, the advantages/disadvantages of a such change are similar to the advantages/disadvantages of a service according its level of granularity.<br></div></blockquote><div><br></div></div>This is indeed an interesting use case ! And as you said we should really consider the impact of sending an huge message ( + UPS refactoring) Vs Sending hundred thousands messages. <div>
<br></div><div>But considering "the big send" option and thinking aloud, even if it the messages are <font face="arial, sans-serif">personalized, probably most of the message will be identical with just some variables changing. We could have a message template, and the map of clients (alias in UPS terminology) would contain values for variables, pseudo code : </font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">{"message":"You won <amount> with this <stock>","alias":{["bob":{"amount"=50,"stock"="Shell"} , </font><span style="font-family:arial,sans-serif">"john":{"amount"=120,"stock"="Esso"}]}</span></div>
</div></div></div></blockquote><div><br></div><div><br></div><div>templating is an interesting thought, but.... </div><div><br></div><div><span style="font-family:arial,sans-serif"><br></span></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif">This will limit the size of the "big send" but implies some logic processing on the UPS side which is maybe not the best idea (even if this templating is generic and not related to any business logic).</span> </div>
</div></div></div></blockquote><div><br></div><div><br></div><div><div><span style="font-family:arial,sans-serif">Right, we (the server) have than to figure out all that, and submit a bunch of messages... I guess unless we have no real requirement for that, let's not do that; Also I don't like the closer tie to the business app. The UnifiedPush Server is not an ESB ;)</span></div>
</div><div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif">-M</span></div><div><span style="font-family:arial,sans-serif"><br>
</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
<br>
<b>Fine Grained</b><br>
+ simplicity and less business logic on server side<br>
+ less amount of data exchanged between client/server<br>
- a lot of interactions between client/server<br>
- more interactions = more network overhead<br>
- complex client side<br></div></blockquote></div><div>Why ? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
<div>
<br>
<b>Coarse Grained</b><br>
+ less interactions between client/server <br>
+ less network overhead & possibility of re-using the same network connection to send messages to the Push Networks (at least for APN)<br>
+ simple client side<br>
- much data exchanged in each interaction between client/server<br>
- complex server side
</div>
<br></div>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div></div>
<br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br>
<br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div>