[aerogear-dev] Sync Day 3 Sync takes Manhattan

[Matthias Wessendorf]

On Thu, Jan 30, 2014 at 9:24 PM, Summers Pittman <supittma at redhat.com>wrote:

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



yay!


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

Nope, that's perfect


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

+1



>
> 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 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/5e7f2b79/attachment-0001.html