<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 27, 2013 at 10:35 AM, Apostolos Emmanouilidis <span dir="ltr">&lt;<a href="mailto:aemmanou@redhat.com" target="_blank">aemmanou@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>


  
  

<div><div class="im">
On Fri, 2013-09-27 at 09:49 +0200, Sebastien Blanc wrote:
<blockquote type="CITE">
    On Fri, Sep 27, 2013 at 9:12 AM, Apostolos Emmanouilidis &lt;<a href="mailto:aemmanou@redhat.com" target="_blank">aemmanou@redhat.com</a>&gt; wrote:<br>
    <br>
</blockquote>
<blockquote type="CITE">
    <blockquote>
        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&#39;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>
        <br>
    </blockquote>
</blockquote>
<blockquote type="CITE">
    <br>
    <br>
</blockquote>
<blockquote type="CITE">
    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. 
</blockquote>
<blockquote type="CITE">
    <br>
    <br>
</blockquote>
<blockquote type="CITE">
    But considering &quot;the big send&quot; option and thinking aloud, even if it the messages are 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 : 
</blockquote>
<blockquote type="CITE">
    <br>
    <br>
</blockquote>
<blockquote type="CITE">
    {&quot;message&quot;:&quot;You won &lt;amount&gt; with this &lt;stock&gt;&quot;,&quot;alias&quot;:{[&quot;bob&quot;:{&quot;amount&quot;=50,&quot;stock&quot;=&quot;Shell&quot;} , &quot;john&quot;:{&quot;amount&quot;=120,&quot;stock&quot;=&quot;Esso&quot;}]}
</blockquote>
<blockquote type="CITE">
    <br>
    <br>
</blockquote>
<blockquote type="CITE">
    This will limit the size of the &quot;big send&quot; 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). 
</blockquote>
<blockquote type="CITE">
    <br>
    <br>
</blockquote>
<blockquote type="CITE">
    <blockquote>
        <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
    </blockquote>
</blockquote>
<blockquote type="CITE">
    Why ?  <br>
</blockquote></div>
If the question goes to the &quot;complex client side&quot; point, I guess that a more sophisticated solution is required on the client side than creating a loop and &quot;firing&quot; the ag-ups :)<div class="im"><br></div>
</div></blockquote><div style>Ah ok :) you mean the &quot;backend&quot; client sending the messages to the UPS. Sorry was confused , I was thinking about the &quot;device&quot; clients. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="im">
<br>
<blockquote type="CITE">
    <blockquote>
        <br>
        <b>Coarse Grained</b><br>
        + less interactions between client/server <br>
        + less network overhead &amp; 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
    </blockquote>
</blockquote>
<blockquote type="CITE">
    <blockquote>
        <br>
        _______________________________________________<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>
    </blockquote>
</blockquote>
<blockquote type="CITE">
    <br>
    <br>
</blockquote>
<blockquote type="CITE">
<pre>_______________________________________________
aerogear-dev mailing list
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a>
</pre>
</blockquote>
<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></div></div>