<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 29, 2014 at 1:43 PM, Bruno Oliveira <span dir="ltr">&lt;<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">My 2 non technical cents, I really think we should separate &quot;push&quot; from &quot;sync&quot; and integrate later,  bet on simple. In my opinion we are just adding one more level of complexity.<div>
<br>

</div><div>For example: would be perfect to add digital signatures, encrypted data for that storage and all the sick things from security. But that would add an extra level of complexity which would lead us to several months of development.</div>
</div></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">

<div><br></div><div>Is just my opinion, but if you guys think that we REALLY need Push, MVP or whatever atm, that&#39;s fine.</div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Wed, Jan 29, 2014 at 6:03 AM, Matthias Wessendorf <span dir="ltr">&lt;<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Tue, Jan 28, 2014 at 7:22 PM, Summers Pittman <span dir="ltr">&lt;<a href="mailto:supittma@redhat.com" target="_blank">supittma@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">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div>
    <div>On 01/28/2014 11:11 AM, Corinne Krych
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">I think we still need the synchronisation mode in
        pull mode.
        <div><br>
        </div>
        <div>How are we going to deal with this use case with simple
          push:
          <div>UserA is offline update some data, then switch off his
            phone</div>
          <div>Some other users update data</div>
          <div>UserA open his app, he has missed some push notifications
            but still want to sync his app.</div>
        </div>
      </div>
    </blockquote></div>
    That is the magic of Push systems.  He gets the messages when he
    comes online.<br>
    <br>
    Device A and B and Server have data with a checksum of 42.<br>
    Device A goes offline.<br>
    Device A changes its data and has a checksum of 64.<br>
    Device B changes its data and has a checksum of 192.<br>
    Device B sends the expected server checksum of 42 and its new data
    to the server.  <br>
    Server accepts B&#39;s Data, updates its checksum to 192, and sends a
    message to all Devices ( in this case just A)<br></div></blockquote><div><br></div></div><div>sending the data does not work via &#39;mobile push&#39; - we need something like &#39;real-time&#39; for that sending;</div>


<div><div><div>

 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <br>
    Device B and Server go on a long date, but things don&#39;t work out and
    they end up splitting the check 50/50.  Device B is annoyed because
    she only got a salad but Server got the Surf and Turf.<br>
    <br>
    Device A comes online and receives a message from the server.  <br>
    Device A notices the server&#39;s checksum data is a change from 42
    -&gt; 192 and not 42 -&gt; 64.  Thus its copy is out of sync and
    fires a message to the User of Device A to resolve the data.<br>
    User A resolves the data and Device A sends the merged data to the
    server.<br>
    Device B gets a message of new data and updates to what the server
    has.<div><div><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div><br>
          </div>
        </div>
        <div>++</div>
        <div>Corinne</div>
      </div>
      <div class="gmail_extra">
        <br>
        <br>
        <div class="gmail_quote">On 28 January 2014 17:01, Summers
          Pittman <span dir="ltr">&lt;<a href="mailto:supittma@redhat.com" target="_blank">supittma@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">
            <div>
              <div>On 01/28/2014 10:58 AM, Lucas Holmquist
                wrote:<br>
                &gt; On Jan 28, 2014, at 10:54 AM, Summers Pittman &lt;<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>&gt;
                wrote:<br>
                &gt;<br>
                &gt;&gt; On 01/28/2014 10:48 AM, Lucas Holmquist wrote:<br>
                &gt;&gt;&gt; On Jan 28, 2014, at 10:30 AM, Summers
                Pittman &lt;<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>&gt;
                wrote:<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; On 01/28/2014 09:36 AM, Lucas Holmquist
                wrote:<br>
                &gt;&gt;&gt;&gt;&gt; yup, this is another Data Sync
                thread,<br>
                &gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;  From a client side
                perspective, i have concerns that there is still not a
                clear direction yet.<br>
                &gt;&gt;&gt;&gt;&gt; I know there are multiple ideas
                floating around on what our model should be,  i&#39;m all
                for choice, but what about deciding on 1 model to get
                started with.  Then later once we have this nailed down,
                 we can have other &quot;adapters&quot; with different models
                perhaps<br>
                &gt;&gt;&gt;&gt; All the data model is is an envelope of
                sync metadata around an object<br>
                &gt;&gt;&gt;&gt; right?<br>
                &gt;&gt;&gt; right<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; We also need to think about the API and
                server/client protocol as well.<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; I think that for sync 1.0 we could
                focus on the following behavior (it<br>
                &gt;&gt;&gt;&gt; worked for my demos at least)<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; 1.  We have a Sync factory similar to
                Pipeline, Authenticator,<br>
                &gt;&gt;&gt;&gt; Registrar, and KeyService.<br>
                &gt;&gt;&gt;&gt; 2.  The Sync factory consumes/manages
                Synchronizer instances.<br>
                &gt;&gt;&gt;&gt; 3.  AG Synchronizer listens for sync
                messages using UnifiedPush endpoints.<br>
                &gt;&gt;&gt; i thought for a 1.0 we weren&#39;t thinking
                about &quot;realtime&quot;<br>
                &gt;&gt; When I hear realtime I think sub 100 ms updates
                to all clients. (think<br>
                &gt;&gt; gaming)<br>
                &gt;&gt;<br>
                &gt;&gt; What I thought we were going for was something
                closer to email.  The<br>
                &gt;&gt; data gets changed and at some point in the
                future the client knows. More<br>
                &gt;&gt; specifically, the thing the ONE thing that
                makes sync special is it is a<br>
                &gt;&gt; push instead of poll implementation.<br>
                &gt; this makes sense,  but i guess it would be push
                when available. thinking web and crappy web socket
                support( dang you carriers )<br>
              </div>
            </div>
            Right.  I&#39;m not saying lets do something complicated.  I&#39;m
            saying lets<br>
            use GCM, iOS CM, and simple push to send notifications to
            tell the<br>
            client something.  In simplePush case it is &quot;this data
            changed, get the<br>
            new stuff and update yourself&quot;.  In Android and iOS case it
            may be that<br>
            or it may be &quot;here is new data&quot;.<br>
            <br>
            In general, I am fine for getting a message saying something
            like<br>
            Documents/Schedules/1/${revision}.  Then I can check my
            revisions, fetch<br>
            data if necessary, update my local data, and send any
            updates.  That<br>
            SHOULD (I think) be doable with simplepush as well right?<br>
            <div>
              <div><br>
                &gt;<br>
                &gt;&gt;&gt;&gt; 4.  AG Synchronizer sends sync messages
                using Pipes<br>
                &gt;&gt;&gt;&gt; 5.  AG Synchronizer holds local data in
                a store<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; 6.  When AGSynchronizer gets a message
                it is responsible for updating<br>
                &gt;&gt;&gt;&gt; the Store and then notifying code
                listing for updates OR for notifying<br>
                &gt;&gt;&gt;&gt; the code that an error has occurred and
                needs to be addressed.<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; 7.  When the developer updates data in
                the store, the synchronizer<br>
                &gt;&gt;&gt;&gt; should package that data and send it to
                the server.  The synchronizer is<br>
                &gt;&gt;&gt;&gt; responsible for error handling,
                retrying, back-off, etc.<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; 8.  We should include multiple
                synchronizer implementations to deal with<br>
                &gt;&gt;&gt;&gt; multiple very simple use cases which
                involve legacy systems. (For<br>
                &gt;&gt;&gt;&gt; instance polling to load static data on
                a schedule.)<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Thoughts? Tomatoes?<br>
                &gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;
                _______________________________________________<br>
                &gt;&gt;&gt;&gt;&gt; aerogear-dev mailing list<br>
                &gt;&gt;&gt;&gt;&gt; <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
                &gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
                &gt;&gt;&gt;&gt;
                _______________________________________________<br>
                &gt;&gt;&gt;&gt; aerogear-dev mailing list<br>
                &gt;&gt;&gt;&gt; <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
                &gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
                &gt;&gt;&gt;
                _______________________________________________<br>
                &gt;&gt;&gt; aerogear-dev mailing list<br>
                &gt;&gt;&gt; <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
                &gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
                &gt;&gt; _______________________________________________<br>
                &gt;&gt; aerogear-dev mailing list<br>
                &gt;&gt; <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
                &gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
                &gt;<br>
                &gt; _______________________________________________<br>
                &gt; aerogear-dev mailing list<br>
                &gt; <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
                &gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
                <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><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <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></div>

<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><br></blockquote></div></div></div><br><br clear="all"><div><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></div>
<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><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div></div>
</div><span class="HOEnZb"><font color="#888888">-- <br>

&quot;The measure of a man is what he does with power&quot; - Plato<br>-<br>@abstractj<br>-<br>Volenti Nihil Difficile
</font></span></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>