<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:32 AM, Matthias
Wessendorf wrote:<br>
</div>
<blockquote
cite="mid:CAAg5f2SHGZ+o8kVFti4SwFzzO+W=QP0a23zZQnG9GSiCe4Ks-w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jan 29, 2014 at 5:57 PM, Jay
Balunas <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jbalunas@redhat.com" target="_blank">jbalunas@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Finally
got a chance to read through the whole sync thread :-)<br>
<br>
I'm a big fan keeping it simple, especially for initial
releases. So limiting scope of our initial offering will
be important imo.<br>
<br>
I really like the idea of defining the data model,
protocol, client contract, etc... separate from a specific
implementation. As several have said, those are impl.
details that we can change as needed. For example Push -
I like the idea of using it for notification of updates
(optional, with fallback, & not required), but it
should not be a 1.0 priority imo. It should also be
something that requires no (or minimal) updates from the
app developer when we implement it. At the end of the day
it is just another way to let the app know something has
changed :-)<br>
<br>
As for versioning, I'm concerned over having M1, M2,
etc.... What do you think of sticking with semver 0.1,
0.2, etc...?<br>
<div class="im"><br>
On Jan 29, 2014, at 10:41 AM, Summers Pittman <<a
moz-do-not-send="true"
href="mailto:supittma@redhat.com">supittma@redhat.com</a>>
wrote:<br>
<br>
</div>
<div class="im">> 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>
</div>
+1 and thanks<br>
<div class="im"><br>
><br>
> Also I am going to propose a potential milestone
conga line. 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 <-><br>
> Client Contract<br>
><br>
> * We seem to be in agreement on a basic set of
metadata to be kept for<br>
> each object. [objectId, revision, object].<br>
> * We should have a basic server definition which
supports CRUD and<br>
> keeps our revision numbers in check. This may not
be a server product<br>
> but just a spec that can be implemented by anything
at this point.<br>
> * 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>
<br>
</div>
I would recommend at this point keep it free from
implementation and/or have that implementation be as
simple as possible. This way we can get through to the
next stage quickly, without debating the specific impl.<br>
</blockquote>
<div><br>
</div>
<div>what do you mean ? Just specs and papers ? Not sure I
follow on keeping it "free from implementation"</div>
</div>
</div>
</div>
</blockquote>
Bump. I'm also curious what you meant.<br>
<blockquote
cite="mid:CAAg5f2SHGZ+o8kVFti4SwFzzO+W=QP0a23zZQnG9GSiCe4Ks-w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
><br>
> M2 - Sync Listener w/ Polling based sync listener,
conflict management,<br>
> Serve user management<br>
> * We define on the client how callbacks will work
for alerts when<br>
> remote data changes<br>
> * We implement a listener which polls a data
source and delivers<br>
> changes to the user.<br>
> * We define how conflicts are managed<br>
> * The server should have a basic authentication
and authorization plan<br>
> for controlling how data is synced<br>
<br>
</div>
I agree we need to plan for the future with user
management and security integration, but I might move
that part to a later point release to keep this as simple
as possible.<br>
</blockquote>
<div><br>
</div>
<div>user mgmt - keycloak :-) </div>
<div>Ok, we should not really go there, yet :-))</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Other than my comments above this looks like a good
overall plan :-)<br>
<br>
Once we nail this down we'll want to talk about possible
dates, and how we split time with other priorities as well
(developer experience, getting started, examples, site,
etc....)<br>
<div class="HOEnZb">
<div class="h5"><br>
><br>
> M3 - Push based Sync Listener, Network
Management, Serverside session<br>
> management<br>
> * We will build on our previous Listener work
from M2 to include a<br>
> Push listener that the server can speak to.<br>
> * We will define in the client how network state
and sync state<br>
> interact. IE how to handle errors in fetching
new data when the<br>
> Listener is alerted. (Exponential back off,
retry, etc)<br>
> * The server will need to have some mechanism
for managing user<br>
> "sessions". This is what users are actively
being synced.<br>
><br>
> M4 - "Real Time" Sync Listener. Bidirectional
automatic sync<br>
> * Instead of using push, Realtime Sync uses
something like web<br>
> sockects. to automatically sync local and remote
data.<br>
> * Previous Sync listeners may have to be
upgraded to include "upload"<br>
> abilities.<br>
> * The server will need to support this as well.<br>
><br>
> M5 - Conflict resolution, Error detection and
support<br>
> * Provide a more comprehensive strategy for
managing conflicts.<br>
> * Provide some automated conflict resolvers<br>
> * The server could get a larger set of conflict
and errors messages<br>
><br>
> M6 - Sync connection Upgrading<br>
> * The client and server will negotiate when it
is appropriate to<br>
> switch between polling, push, and realtime sync
strategies.<br>
><br>
> M7 - Party<br>
> * We have a sync party.<br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">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>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">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>
</div>
</div>
</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>