[aerogear-dev] Sync Day 2: All our cars are frozen in ice

[Summers Pittman]

On Wed 29 Jan 2014 12:00:26 PM EST, Lucas Holmquist wrote:
>
> On Jan 29, 2014, at 11:57 AM, Jay Balunas <jbalunas at 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…?
>
> +1 to semver

Yeah, I didn't want to lead with version numbers because people tend to 
get hung up on numbers (seeing how we have two comments on that 
already).  I'm more worried about ordering and grouping than numbers.  
By the time we make it into JIRAs and such we will have version numbers.

>>
>> On Jan 29, 2014, at 10:41 AM, Summers Pittman <supittma at 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.
>>
>>>
>>>
>>> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev