I'm going to take some time to roll up yesterday's Sync Thread so we can stop chasing down individual ideas. Also I am going to propose a potential milestone conga line. I think one of the things that keeps happening in these discussions is everyone has an idea of what sync is but we don't really know what order things should be done or released in. If everyone likes this I'll slice things into JIRA epics. # M1 - Basic revision Control, Data Model, Change Management, Server <-> Client Contract * We seem to be in agreement on a basic set of metadata to be kept for each object. [objectId, revision, object]. * We should have a basic server definition which supports CRUD and keeps our revision numbers in check. This may not be a server product but just a spec that can be implemented by anything at this point. * We should have basic client code which keeps up with revisions, can check the server for new revisions, and alert the user if there is a sync conflict. M2 - Sync Listener w/ Polling based sync listener, conflict management, Serve user management * We define on the client how callbacks will work for alerts when remote data changes * We implement a listener which polls a data source and delivers changes to the user. * We define how conflicts are managed * The server should have a basic authentication and authorization plan for controlling how data is synced M3 - Push based Sync Listener, Network Management, Serverside session management

* We will build on our previous Listener work from M2 to include a Push listener that the server can speak to. * We will define in the client how network state and sync state interact. IE how to handle errors in fetching new data when the Listener is alerted. (Exponential back off, retry, etc) * The server will need to have some mechanism for managing user "sessions". This is what users are actively being synced. M4 - "Real Time" Sync Listener. Bidirectional automatic sync * Instead of using push, Realtime Sync uses something like web sockects. to automatically sync local and remote data. * Previous Sync listeners may have to be upgraded to include "upload" abilities. * The server will need to support this as well. M5 - Conflict resolution, Error detection and support * Provide a more comprehensive strategy for managing conflicts. * Provide some automated conflict resolvers * The server could get a larger set of conflict and errors messages M6 - Sync connection Upgrading * The client and server will negotiate when it is appropriate to switch between polling, push, and realtime sync strategies. M7 - Party * We have a sync party. _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 01/29/2014 11:18 AM, Lucas Holmquist wrote: > On Jan 29, 2014, at 10:41 AM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > >> I'm going to take some time to roll up yesterday's Sync Thread so we can >> stop chasing down individual ideas. >> >> Also I am going to propose a potential milestone conga line. I think >> one of the things that keeps happening in these discussions is everyone >> has an idea of what sync is but we don't really know what order things >> should be done or released in. >> >> If everyone likes this I'll slice things into JIRA epics. >> >> # M1 - Basic revision Control, Data Model, Change Management, Server <-> >> Client Contract >> >> * We seem to be in agreement on a basic set of metadata to be kept for >> each object. [objectId, revision, object]. >> * We should have a basic server definition which supports CRUD and >> keeps our revision numbers in check. This may not be a server product >> but just a spec that can be implemented by anything at this point. >> * We should have basic client code which keeps up with revisions, can >> check the server for new revisions, and alert the user if there is a >> sync conflict. >> >> >> M2 - Sync Listener w/ Polling based sync listener, conflict management, >> Serve user management >> * We define on the client how callbacks will work for alerts when >> remote data changes >> * We implement a listener which polls a data source and delivers >> changes to the user. >> * We define how conflicts are managed >> * The server should have a basic authentication and authorization plan >> for controlling how data is synced >> >> M3 - Push based Sync Listener, Network Management, Serverside session >> management > when we say push here, are we talking about the 3rd party services such as GCM and APN's, if so, not sure that is a great idea A one way notification service which only guarantees eventual delivery. GCM and APN is an example of this type of service but I explicitly left it out and think we should target consuming messages from the unified push server. This may mean that we implement SimplePush on iOS and Android so we are "pure" and bundle the simple push server into the sync server contract. > >> * We will build on our previous Listener work from M2 to include a >> Push listener that the server can speak to. >> * We will define in the client how network state and sync state >> interact. IE how to handle errors in fetching new data when the >> Listener is alerted. (Exponential back off, retry, etc) >> * The server will need to have some mechanism for managing user >> "sessions". This is what users are actively being synced. >> >> M4 - "Real Time" Sync Listener. Bidirectional automatic sync >> * Instead of using push, Realtime Sync uses something like web >> sockects. to automatically sync local and remote data. >> * Previous Sync listeners may have to be upgraded to include "upload" >> abilities. >> * The server will need to support this as well. >> >> M5 - Conflict resolution, Error detection and support >> * Provide a more comprehensive strategy for managing conflicts. >> * Provide some automated conflict resolvers >> * The server could get a larger set of conflict and errors messages >> >> M6 - Sync connection Upgrading >> * The client and server will negotiate when it is appropriate to >> switch between polling, push, and realtime sync strategies. >> >> M7 - Party >> * We have a sync party. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Wed, Jan 29, 2014 at 8:31 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: Hi All, #agreed Good to have a plan with associated JIRA to help keep the focus on sync. +1 For v0.1, I’d like to have a demo app epic (recipe app). it would be nice to agree on same demo app (to make sure more or less same features are implemented). I’ve started with Buddies’Hobbies app from Luke[1], I’m planning to add to ios-cookbook for our initial sync. Ok to add a demo JIRA for that? or any better idea for demo app? You mean a demo app in addition, right?

To me v0.1 and v0.2 could be grouped together. v0.2 should be without auth and authz to stay focus on pluggable confilct mgt and sync/reconciliation trigger(or listener) hrm, not sure tbh

v0.3 could be focus on auth/authz and then as you stated Another important thing to help collaborative work would be to agree on vocabulary. I like the terms used by Fabrice in its gist[2] like confict and data set reconciliation (in v0.1 we stick to wholesale transfert). In spec doc we should refine vocabulary, let’s have a JIRa for that too… While you’re at planning task summers (doing the Epics) maybe it could be a good idea to start a sync roadmap page in ag.org[3]? ++ Corinne [1] https://github.com/lholmquist/ag-js-ds-poc [2] https://gist.github.com/fabricematrat/8666682 [3] https://github.com/aerogear/aerogear.org/tree/master/docs/planning/roadmaps On 29 Jan 2014, at 18:11, Summers Pittman <supittma(a)redhat.com&gt; wrote: > On 01/29/2014 11:18 AM, Lucas Holmquist wrote: >> On Jan 29, 2014, at 10:41 AM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >> >>> I'm going to take some time to roll up yesterday's Sync Thread so we can >>> stop chasing down individual ideas. >>> >>> Also I am going to propose a potential milestone conga line. I think >>> one of the things that keeps happening in these discussions is everyone >>> has an idea of what sync is but we don't really know what order things >>> should be done or released in. >>> >>> If everyone likes this I'll slice things into JIRA epics. >>> >>> # M1 - Basic revision Control, Data Model, Change Management, Server <-> >>> Client Contract >>> >>> * We seem to be in agreement on a basic set of metadata to be kept for >>> each object. [objectId, revision, object]. >>> * We should have a basic server definition which supports CRUD and >>> keeps our revision numbers in check. This may not be a server product >>> but just a spec that can be implemented by anything at this point. >>> * We should have basic client code which keeps up with revisions, can >>> check the server for new revisions, and alert the user if there is a >>> sync conflict. >>> >>> >>> M2 - Sync Listener w/ Polling based sync listener, conflict management, >>> Serve user management >>> * We define on the client how callbacks will work for alerts when >>> remote data changes >>> * We implement a listener which polls a data source and delivers >>> changes to the user. >>> * We define how conflicts are managed >>> * The server should have a basic authentication and authorization plan >>> for controlling how data is synced >>> >>> M3 - Push based Sync Listener, Network Management, Serverside session >>> management >> when we say push here, are we talking about the 3rd party services such as GCM and APN's, if so, not sure that is a great idea > A one way notification service which only guarantees eventual delivery. > GCM and APN is an example of this type of service but I explicitly left > it out and think we should target consuming messages from the unified > push server. This may mean that we implement SimplePush on iOS and > Android so we are "pure" and bundle the simple push server into the sync > server contract. >> >>> * We will build on our previous Listener work from M2 to include a >>> Push listener that the server can speak to. >>> * We will define in the client how network state and sync state >>> interact. IE how to handle errors in fetching new data when the >>> Listener is alerted. (Exponential back off, retry, etc) >>> * The server will need to have some mechanism for managing user >>> "sessions". This is what users are actively being synced. >>> >>> M4 - "Real Time" Sync Listener. Bidirectional automatic sync >>> * Instead of using push, Realtime Sync uses something like web >>> sockects. to automatically sync local and remote data. >>> * Previous Sync listeners may have to be upgraded to include "upload" >>> abilities. >>> * The server will need to support this as well. >>> >>> M5 - Conflict resolution, Error detection and support >>> * Provide a more comprehensive strategy for managing conflicts. >>> * Provide some automated conflict resolvers >>> * The server could get a larger set of conflict and errors messages >>> >>> M6 - Sync connection Upgrading >>> * The client and server will negotiate when it is appropriate to >>> switch between polling, push, and realtime sync strategies. >>> >>> M7 - Party >>> * We have a sync party. >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Jan 30, 2014 at 9:40 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: On 30 Jan 2014, at 09:38, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Wed, Jan 29, 2014 at 8:31 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > Hi All, > > #agreed Good to have a plan with associated JIRA to help keep the focus on sync. > > +1 > > For v0.1, I’d like to have a demo app epic (recipe app). it would be nice to agree on same demo app (to make sure more or less same features are implemented). I’ve started with Buddies’Hobbies app from Luke[1], I’m planning to add to ios-cookbook for our initial sync. > Ok to add a demo JIRA for that? or any better idea for demo app? > > You mean a demo app in addition, right? Yes, a demo app to test our use cases for v0.1 keep it simple like Luke’s demo yeah :-) I agree > > > To me v0.1 and v0.2 could be grouped together. > v0.2 should be without auth and authz to stay focus on pluggable confilct mgt and sync/reconciliation trigger(or listener) > > hrm, not sure tbh Not sure for what grouped 0.1/0.2 or v0.2 without Auth Authz? not sure on the grouping

> > v0.3 could be focus on auth/authz > and then as you stated > > Another important thing to help collaborative work would be to agree on vocabulary. I like the terms used by Fabrice in its gist[2] like confict and data set reconciliation (in v0.1 we stick to wholesale transfert). > In spec doc we should refine vocabulary, let’s have a JIRa for that too… > > While you’re at planning task summers (doing the Epics) maybe it could be a good idea to start a sync roadmap page in ag.org[3]? > > ++ > Corinne > [1] https://github.com/lholmquist/ag-js-ds-poc > [2] https://gist.github.com/fabricematrat/8666682 > [3] https://github.com/aerogear/aerogear.org/tree/master/docs/planning/roadmaps > On 29 Jan 2014, at 18:11, Summers Pittman <supittma(a)redhat.com&gt; wrote: > > On 01/29/2014 11:18 AM, Lucas Holmquist wrote: > >> On Jan 29, 2014, at 10:41 AM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > >> > >>> I'm going to take some time to roll up yesterday's Sync Thread so we can > >>> stop chasing down individual ideas. > >>> > >>> Also I am going to propose a potential milestone conga line. I think > >>> one of the things that keeps happening in these discussions is everyone > >>> has an idea of what sync is but we don't really know what order things > >>> should be done or released in. > >>> > >>> If everyone likes this I'll slice things into JIRA epics. > >>> > >>> # M1 - Basic revision Control, Data Model, Change Management, Server <-> > >>> Client Contract > >>> > >>> * We seem to be in agreement on a basic set of metadata to be kept for > >>> each object. [objectId, revision, object]. > >>> * We should have a basic server definition which supports CRUD and > >>> keeps our revision numbers in check. This may not be a server product > >>> but just a spec that can be implemented by anything at this point. > >>> * We should have basic client code which keeps up with revisions, can > >>> check the server for new revisions, and alert the user if there is a > >>> sync conflict. > >>> > >>> > >>> M2 - Sync Listener w/ Polling based sync listener, conflict management, > >>> Serve user management > >>> * We define on the client how callbacks will work for alerts when > >>> remote data changes > >>> * We implement a listener which polls a data source and delivers > >>> changes to the user. > >>> * We define how conflicts are managed > >>> * The server should have a basic authentication and authorization plan > >>> for controlling how data is synced > >>> > >>> M3 - Push based Sync Listener, Network Management, Serverside session > >>> management > >> when we say push here, are we talking about the 3rd party services such as GCM and APN's, if so, not sure that is a great idea > > A one way notification service which only guarantees eventual delivery. > > GCM and APN is an example of this type of service but I explicitly left > > it out and think we should target consuming messages from the unified > > push server. This may mean that we implement SimplePush on iOS and > > Android so we are "pure" and bundle the simple push server into the sync > > server contract. > >> > >>> * We will build on our previous Listener work from M2 to include a > >>> Push listener that the server can speak to. > >>> * We will define in the client how network state and sync state > >>> interact. IE how to handle errors in fetching new data when the > >>> Listener is alerted. (Exponential back off, retry, etc) > >>> * The server will need to have some mechanism for managing user > >>> "sessions". This is what users are actively being synced. > >>> > >>> M4 - "Real Time" Sync Listener. Bidirectional automatic sync > >>> * Instead of using push, Realtime Sync uses something like web > >>> sockects. to automatically sync local and remote data. > >>> * Previous Sync listeners may have to be upgraded to include "upload" > >>> abilities. > >>> * The server will need to support this as well. > >>> > >>> M5 - Conflict resolution, Error detection and support > >>> * Provide a more comprehensive strategy for managing conflicts. > >>> * Provide some automated conflict resolvers > >>> * The server could get a larger set of conflict and errors messages > >>> > >>> M6 - Sync connection Upgrading > >>> * The client and server will negotiate when it is appropriate to > >>> switch between polling, push, and realtime sync strategies. > >>> > >>> M7 - Party > >>> * We have a sync party. > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Finally got a chance to read through the whole sync thread :-) I'm a big fan keeping it simple, especially for initial releases. So limiting scope of our initial offering will be important imo. 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 :-) As for versioning, I'm concerned over having M1, M2, etc.... What do you think of sticking with semver 0.1, 0.2, etc…?

On Jan 29, 2014, at 10:41 AM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > I'm going to take some time to roll up yesterday's Sync Thread so we can > stop chasing down individual ideas. +1 and thanks > > Also I am going to propose a potential milestone conga line. I think > one of the things that keeps happening in these discussions is everyone > has an idea of what sync is but we don't really know what order things > should be done or released in. > > If everyone likes this I'll slice things into JIRA epics. > > # M1 - Basic revision Control, Data Model, Change Management, Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. 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. > > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > Serve user management > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > * The server should have a basic authentication and authorization plan > for controlling how data is synced 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. Other than my comments above this looks like a good overall plan :-) 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....) > > M3 - Push based Sync Listener, Network Management, Serverside session > management > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > > M4 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > * Previous Sync listeners may have to be upgraded to include "upload" > abilities. > * The server will need to support this as well. > > M5 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > M6 - Sync connection Upgrading > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > > M7 - Party > * We have a sync party. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jan 29, 2014, at 11:57 AM, Jay Balunas <jbalunas(a)redhat.com&gt; wrote: > Finally got a chance to read through the whole sync thread :-) > > I'm a big fan keeping it simple, especially for initial releases. So limiting scope of our initial offering will be important imo. > > 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 :-) > > As for versioning, I'm concerned over having M1, M2, etc.... What do you think of sticking with semver 0.1, 0.2, etc...? +1 to semver

On Wed, Jan 29, 2014 at 5:57 PM, Jay Balunas <jbalunas(a)redhat.com <mailto:jbalunas@redhat.com>> wrote: Finally got a chance to read through the whole sync thread :-) I'm a big fan keeping it simple, especially for initial releases. So limiting scope of our initial offering will be important imo. 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 :-) As for versioning, I'm concerned over having M1, M2, etc.... What do you think of sticking with semver 0.1, 0.2, etc...? On Jan 29, 2014, at 10:41 AM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: > I'm going to take some time to roll up yesterday's Sync Thread so we can > stop chasing down individual ideas. +1 and thanks > > Also I am going to propose a potential milestone conga line. I think > one of the things that keeps happening in these discussions is everyone > has an idea of what sync is but we don't really know what order things > should be done or released in. > > If everyone likes this I'll slice things into JIRA epics. > > # M1 - Basic revision Control, Data Model, Change Management, Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. 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. what do you mean ? Just specs and papers ? Not sure I follow on keeping it "free from implementation"

> > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > Serve user management > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > * The server should have a basic authentication and authorization plan > for controlling how data is synced 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. user mgmt - keycloak :-) Ok, we should not really go there, yet :-)) Other than my comments above this looks like a good overall plan :-) 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....) > > M3 - Push based Sync Listener, Network Management, Serverside session > management > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > > M4 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > * Previous Sync listeners may have to be upgraded to include "upload" > abilities. > * The server will need to support this as well. > > M5 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > M6 - Sync connection Upgrading > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > > M7 - Party > * We have a sync party. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Wed, Jan 29, 2014 at 4:41 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: I'm going to take some time to roll up yesterday's Sync Thread so we can stop chasing down individual ideas. Also I am going to propose a potential milestone conga line. I think one of the things that keeps happening in these discussions is everyone has an idea of what sync is but we don't really know what order things should be done or released in. If everyone likes this I'll slice things into JIRA epics. # M1 - Basic revision Control, Data Model, Change Management, Server <-> Client Contract * We seem to be in agreement on a basic set of metadata to be kept for each object. [objectId, revision, object]. * We should have a basic server definition which supports CRUD and keeps our revision numbers in check. This may not be a server product but just a spec that can be implemented by anything at this point. * We should have basic client code which keeps up with revisions, can check the server for new revisions, and alert the user if there is a sync conflict. what about looking at local changes ? Is that implied here?

M2 - Sync Listener w/ Polling based sync listener, conflict management, Serve user management * We define on the client how callbacks will work for alerts when remote data changes * We implement a listener which polls a data source and delivers changes to the user. * We define how conflicts are managed * The server should have a basic authentication and authorization plan for controlling how data is synced Not sure, but: could/should a user get the chance to kinda control that 'change' (e.g. veto) ?

M3 - Push based Sync Listener, Network Management, Serverside session management * We will build on our previous Listener work from M2 to include a Push listener that the server can speak to. * We will define in the client how network state and sync state interact. IE how to handle errors in fetching new data when the Listener is alerted. (Exponential back off, retry, etc) * The server will need to have some mechanism for managing user "sessions". This is what users are actively being synced. I still think this is optional :-) I think generally it's nice to have feature that the "sync-server" can send 'update requests' to the unifiedpush server; However IMO the clients should still mark this as optional (again a user (on iOS/FFOS) can decide she is not interested in push notification; Than all the offerings from M3 would just not work

M4 - "Real Time" Sync Listener. Bidirectional automatic sync * Instead of using push, Realtime Sync uses something like web sockects. to automatically sync local and remote data. Should be the default when an app is active and open (putting platform limits aside)

* Previous Sync listeners may have to be upgraded to include "upload" abilities. * The server will need to support this as well. This step might allow us (*later*) to plug in some sort of OT (Operational Transform) implementation

M5 - Conflict resolution, Error detection and support * Provide a more comprehensive strategy for managing conflicts. * Provide some automated conflict resolvers * The server could get a larger set of conflict and errors messages +1 M6 - Sync connection Upgrading * The client and server will negotiate when it is appropriate to switch between polling, push, and realtime sync strategies. yeah, sounds good

M7 - Party * We have a sync party. Jägermeister and fine brews from Russian River -> yay!

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Oh, did you get a chance to read the mail/gist from Fabrice? * http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Conflicts-amp-Reco... * https://gist.github.com/fabricematrat/8666682

-M On Wed, Jan 29, 2014 at 4:41 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: I'm going to take some time to roll up yesterday's Sync Thread so we can stop chasing down individual ideas. Also I am going to propose a potential milestone conga line. I think one of the things that keeps happening in these discussions is everyone has an idea of what sync is but we don't really know what order things should be done or released in. If everyone likes this I'll slice things into JIRA epics. # M1 - Basic revision Control, Data Model, Change Management, Server <-> Client Contract * We seem to be in agreement on a basic set of metadata to be kept for each object. [objectId, revision, object]. * We should have a basic server definition which supports CRUD and keeps our revision numbers in check. This may not be a server product but just a spec that can be implemented by anything at this point. * We should have basic client code which keeps up with revisions, can check the server for new revisions, and alert the user if there is a sync conflict. M2 - Sync Listener w/ Polling based sync listener, conflict management, Serve user management * We define on the client how callbacks will work for alerts when remote data changes * We implement a listener which polls a data source and delivers changes to the user. * We define how conflicts are managed * The server should have a basic authentication and authorization plan for controlling how data is synced M3 - Push based Sync Listener, Network Management, Serverside session management * We will build on our previous Listener work from M2 to include a Push listener that the server can speak to. * We will define in the client how network state and sync state interact. IE how to handle errors in fetching new data when the Listener is alerted. (Exponential back off, retry, etc) * The server will need to have some mechanism for managing user "sessions". This is what users are actively being synced. M4 - "Real Time" Sync Listener. Bidirectional automatic sync * Instead of using push, Realtime Sync uses something like web sockects. to automatically sync local and remote data. * Previous Sync listeners may have to be upgraded to include "upload" abilities. * The server will need to support this as well. M5 - Conflict resolution, Error detection and support * Provide a more comprehensive strategy for managing conflicts. * Provide some automated conflict resolvers * The server could get a larger set of conflict and errors messages M6 - Sync connection Upgrading * The client and server will negotiate when it is appropriate to switch between polling, push, and realtime sync strategies. M7 - Party * We have a sync party. _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev