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

[Matthias Wessendorf]

On Wed, Jan 29, 2014 at 5:57 PM, 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...?
>
> 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.
>

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 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
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/c0a6ecbe/attachment.html