<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 01/30/2014 03:22 AM, Matthias
      Wessendorf wrote:<br>
    </div>
    <blockquote
cite="mid:CAAg5f2R_YScMrycPgUay+v0CnY_VhranZXwiCma5aKdAkxa7oA@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <br>
          <div class="gmail_quote">On Wed, Jan 29, 2014 at 4:41 PM,
            Summers Pittman <span dir="ltr">&lt;<a
                moz-do-not-send="true" href="mailto:supittma@redhat.com"
                target="_blank">supittma@redhat.com</a>&gt;</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">I'm
              going to take some time to roll up yesterday's Sync Thread
              so we can<br>
              stop chasing down individual ideas.<br>
              <br>
              Also I am going to propose a potential milestone conga
              line. &nbsp;I think<br>
              one of the things that keeps happening in these
              discussions is everyone<br>
              has an idea of what sync is but we don't really know what
              order things<br>
              should be done or released in.<br>
              <br>
              If everyone likes this I'll slice things into JIRA epics.<br>
              <br>
              # M1 - Basic revision Control, Data Model, Change
              Management, Server &lt;-&gt;<br>
              Client Contract<br>
              <br>
              &nbsp; * We seem to be in agreement on a basic set of metadata
              to be kept for<br>
              each object. &nbsp;[objectId, revision, object].<br>
              &nbsp; * We should have a basic server definition which
              supports CRUD and<br>
              keeps our revision numbers in check. &nbsp;This may not be a
              server product<br>
              but just a spec that can be implemented by anything at
              this point.<br>
              &nbsp; * We should have basic client code which keeps up with
              revisions, can<br>
              check the server for new revisions, and alert the user if
              there is a<br>
              sync conflict.<br>
            </blockquote>
            <div><br>
            </div>
            <div>what about looking at local changes ? Is that implied
              here? <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Right.&nbsp; Basically the first thing we should have is some way of
    detecting if the local data and server data are out of sync with one
    another.<br>
    <br>
    I'll follow up later with a bit more indepth discussion on how we do
    that.&nbsp; (Diff-merge-patch and revision control are the two being
    worked on in the sync server right now).<br>
    <br>
    <blockquote
cite="mid:CAAg5f2R_YScMrycPgUay+v0CnY_VhranZXwiCma5aKdAkxa7oA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>&nbsp;</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"><br>
              <br>
              M2 - Sync Listener w/ Polling based sync listener,
              conflict management,<br>
              Serve user management<br>
              &nbsp; * We define on the client how callbacks will work for
              alerts when<br>
              remote data changes<br>
              &nbsp; * We implement a listener which polls a data source and
              delivers<br>
              changes to the user.<br>
              &nbsp; * We define how conflicts are managed<br>
              &nbsp; * The server should have a basic authentication and
              authorization plan<br>
              for controlling how data is synced<br>
            </blockquote>
            <div><br>
            </div>
            <div>Not sure, but: could/should a &nbsp;user get the chance to
              kinda control that 'change' (e.g. veto) ?</div>
          </div>
        </div>
      </div>
    </blockquote>
    It depends on the architecture of the application.&nbsp; In a peer to
    peer system like say email then maybe.&nbsp; In a client/server system
    like mediawiki then that is probably a no.<br>
    <br>
    Something to think about on the JIRA.<br>
    <br>
    <blockquote
cite="mid:CAAg5f2R_YScMrycPgUay+v0CnY_VhranZXwiCma5aKdAkxa7oA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>&nbsp;</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"><br>
              M3 - Push based Sync Listener, Network Management,
              Serverside session<br>
              management<br>
              &nbsp; * We will build on our previous Listener work from M2 to
              include a<br>
              Push listener that the server can speak to.<br>
              &nbsp; * We will define in the client how network state and
              sync state<br>
              interact. &nbsp;IE how to handle errors in fetching new data
              when the<br>
              Listener is alerted. (Exponential back off, retry, etc)<br>
              &nbsp; * The server will need to have some mechanism for
              managing user<br>
              "sessions". &nbsp;This is what users are actively being synced.<br>
            </blockquote>
            <div><br>
            </div>
            <div>I still think this is optional :-)</div>
            <div><br>
            </div>
            <div>I think generally it's nice to have feature that the
              "sync-server" can send 'update requests'</div>
            <div>to the unifiedpush server; However IMO the clients
              should still mark this as optional (again</div>
            <div>a user (on iOS/FFOS) can decide she is not interested
              in push notification; Than all the offerings</div>
            <div>from M3 would just not work</div>
          </div>
        </div>
      </div>
    </blockquote>
    Yes a user on iOS and FFx can turn off parts of M3.&nbsp; However M3
    builds the foundation for M4.<br>
    <br>
    Additionally network management and intermittent connectivity ARE
    problems for all platforms and they are also addressed in this
    bundle.<br>
    <br>
    <blockquote
cite="mid:CAAg5f2R_YScMrycPgUay+v0CnY_VhranZXwiCma5aKdAkxa7oA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>&nbsp;</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"><br>
              M4 - "Real Time" Sync Listener. &nbsp;Bidirectional automatic
              sync<br>
              &nbsp; * Instead of using push, Realtime Sync uses something
              like web<br>
              sockects. to automatically sync local and remote data.<br>
            </blockquote>
            <div><br>
            </div>
            <div>Should be the default when an app is active and open
              (putting platform limits aside)</div>
          </div>
        </div>
      </div>
    </blockquote>
    Managing that is what M6 is about.<br>
    <blockquote
cite="mid:CAAg5f2R_YScMrycPgUay+v0CnY_VhranZXwiCma5aKdAkxa7oA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>&nbsp;</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">&nbsp;
              * Previous Sync listeners may have to be upgraded to
              include "upload"<br>
              abilities.<br>
              &nbsp; * The server will need to support this as well.<br>
            </blockquote>
            <div><br>
            </div>
            <div>This step might allow us (*later*) to plug in some sort
              of&nbsp;OT (Operational Transform) implementation<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Well before this the way uploading was done was out of band with the
    sync channel.&nbsp; Before M4 this was one way sync (server -&gt; client)
    with the application pushing changes to the server.&nbsp; Now the idea is
    that library will have support for pushing changes automatically.<br>
    <blockquote
cite="mid:CAAg5f2R_YScMrycPgUay+v0CnY_VhranZXwiCma5aKdAkxa7oA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>&nbsp;</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"><br>
              M5 - Conflict resolution, Error detection and support<br>
              &nbsp; * Provide a more comprehensive strategy for managing
              conflicts.<br>
              &nbsp; * Provide some automated conflict resolvers<br>
              &nbsp; * The server could get a larger set of conflict and
              errors messages<br>
            </blockquote>
            <div><br>
            </div>
            <div>+1</div>
            <div>&nbsp;</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"><br>
              M6 - Sync connection Upgrading<br>
              &nbsp; * The client and server will negotiate when it is
              appropriate to<br>
              switch between polling, push, and realtime sync
              strategies.<br>
            </blockquote>
            <div><br>
            </div>
            <div>yeah, sounds good</div>
          </div>
        </div>
      </div>
    </blockquote>
    Maybe this should be moved to before automagic conflict resolution
    (M5)<br>
    <blockquote
cite="mid:CAAg5f2R_YScMrycPgUay+v0CnY_VhranZXwiCma5aKdAkxa7oA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>&nbsp;</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"><br>
              M7 - Party<br>
              &nbsp; * We have a sync party.<br>
            </blockquote>
            <div><br>
            </div>
            <div>J&auml;germeister and fine brews from Russian River -&gt;
              yay!</div>
          </div>
        </div>
      </div>
    </blockquote>
    :-D<br>
    <blockquote
cite="mid:CAAg5f2R_YScMrycPgUay+v0CnY_VhranZXwiCma5aKdAkxa7oA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>&nbsp;</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">_______________________________________________<br>
              aerogear-dev mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:aerogear-dev@lists.jboss.org"
                target="_blank">aerogear-dev@lists.jboss.org</a><br>
              <a moz-do-not-send="true"
                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 moz-do-not-send="true"
            href="http://matthiaswessendorf.wordpress.com/"
            target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
          sessions: <a moz-do-not-send="true"
            href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
          twitter: <a moz-do-not-send="true"
            href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
aerogear-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></pre>
    </blockquote>
    <br>
  </body>
</html>