Re: [aerogear-dev] Sync Day 3 Sync takes Manhattan

I've turned M1 into a Jira https://issues.jboss.org/browse/AEROGEAR-1405

Is there any complain to turning each M into an Epic and each bullet into a subtask in that Epic?

In theory from here we can group them into versions and releases.

On 01/30/2014 10:23 AM, Summers Pittman wrote: > I rolled up the feedback to the email I sent yesterday. > > One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan. It is > probably closer to a 1.5 or 2.0 plan in terms of scope. I tried to > order things and break out big "chunks" which will need to be done and > the approximate order they should be done in while also drawing a line > around what features we have. This is why I have not placed ANY > versions YET. By the end of today/tomorrow morning I hope that we will > be in a good place to do that. > > Big changes from yesterday, User mgmt moved to M4. M6 (Sync Listener > Upgrading)was merged into M3(Push Listeners) so that we can have > optional push sooner. > > # 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, > > * 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 > > > M3 - Push based Sync Listener, Sync Listener Strategy Management > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will support ways of automagically managing sync listeners based > on the availability of Push. > > M4 - Server user management, Network Management, Server side session > management > * 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. > * The server should have a basic authentication and authorization plan > for controlling how data is synced > > M5 - "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. > * We will also include the ability to switch between Realtime sync > listeners, polling listeners, and push listeners > * The server will need to support this as well. > > M6 - 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 > > M8 - 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