<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 9:24 PM, Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've turned M1 into a Jira <a href="https://issues.jboss.org/browse/AEROGEAR-1405" target="_blank">https://issues.jboss.org/browse/AEROGEAR-1405</a></blockquote>
<div><br></div><div><br></div><div>yay!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Is there any complain to turning each M into an Epic and each bullet<br>
into a subtask in that Epic?<br></blockquote><div><br></div><div>Nope, that's perfect</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In theory from here we can group them into versions and releases.<br></blockquote><div><br></div><div>+1</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On 01/30/2014 10:23 AM, Summers Pittman wrote:<br>
> I rolled up the feedback to the email I sent yesterday.<br>
><br>
> One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan. It is<br>
> probably closer to a 1.5 or 2.0 plan in terms of scope. I tried to<br>
> order things and break out big "chunks" which will need to be done and<br>
> the approximate order they should be done in while also drawing a line<br>
> around what features we have. This is why I have not placed ANY<br>
> versions YET. By the end of today/tomorrow morning I hope that we will<br>
> be in a good place to do that.<br>
><br>
> Big changes from yesterday, User mgmt moved to M4. M6 (Sync Listener<br>
> Upgrading)was merged into M3(Push Listeners) so that we can have<br>
> optional push sooner.<br>
><br>
> # M1 - Basic revision Control, Data Model, Change Management, Server <-><br>
> Client Contract<br>
><br>
> * We seem to be in agreement on a basic set of metadata to be kept for<br>
> each object. [objectId, revision, object].<br>
> * We should have a basic server definition which supports CRUD and<br>
> keeps our revision numbers in check. This may not be a server product<br>
> but just a spec that can be implemented by anything at this point.<br>
> * We should have basic client code which keeps up with revisions, can<br>
> check the server for new revisions, and alert the user if there is a<br>
> sync conflict.<br>
><br>
><br>
> M2 - Sync Listener w/ Polling based sync listener, conflict management,<br>
><br>
> * We define on the client how callbacks will work for alerts when<br>
> remote data changes<br>
> * We implement a listener which polls a data source and delivers<br>
> changes to the user.<br>
> * We define how conflicts are managed<br>
><br>
><br>
> M3 - Push based Sync Listener, Sync Listener Strategy Management<br>
> * The client and server will negotiate when it is appropriate to<br>
> switch between polling, push, and realtime sync strategies.<br>
> * We will build on our previous Listener work from M2 to include a<br>
> Push listener that the server can speak to.<br>
> * We will support ways of automagically managing sync listeners based<br>
> on the availability of Push.<br>
><br>
> M4 - Server user management, Network Management, Server side session<br>
> management<br>
> * We will define in the client how network state and sync state<br>
> interact. IE how to handle errors in fetching new data when the<br>
> Listener is alerted. (Exponential back off, retry, etc)<br>
> * The server will need to have some mechanism for managing user<br>
> "sessions". This is what users are actively being synced.<br>
> * The server should have a basic authentication and authorization plan<br>
> for controlling how data is synced<br>
><br>
> M5 - "Real Time" Sync Listener. Bidirectional automatic sync<br>
> * Instead of using push, Realtime Sync uses something like web<br>
> sockects. to automatically sync local and remote data.<br>
> * Previous Sync listeners may have to be upgraded to include "upload"<br>
> abilities.<br>
> * We will also include the ability to switch between Realtime sync<br>
> listeners, polling listeners, and push listeners<br>
> * The server will need to support this as well.<br>
><br>
> M6 - Conflict resolution, Error detection and support<br>
> * Provide a more comprehensive strategy for managing conflicts.<br>
> * Provide some automated conflict resolvers<br>
> * The server could get a larger set of conflict and errors messages<br>
><br>
> M8 - Party<br>
> * We have a sync party.<br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div>