9:23 a.m.
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.
9:26 a.m.
I like it.
On 30 Jan 2014, at 16:23, Summers Pittman <supittma(a)redhat.com> 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.
+1
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
10:03 a.m.
On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman <supittma(a)redhat.com>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.
ahm... thinking about 2.0.0 before we have a 1.0.0 ? Not sure I understand
that
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.
+1
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
+1
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.
overall, yes - the nasty details can be discussed at a later point, hence
+1
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
this assume we do have a server w/ pluggable adapters, no ?
E.g. JPA/JavaEE/Hibernate adapters verus YetAnotherDatabaseThingy adapter
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.
Didn't M3 already include 'realtime' ?
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.
what about M7? :)
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
10:13 a.m.
On 01/30/2014 11:03 AM, Matthias Wessendorf wrote:
On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> 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.
ahm... thinking about 2.0.0 before we have a 1.0.0 ? Not sure I
understand that
The point I was trying to make is that I'm not expecting
everything on
here to get done quickly from top to bottom and slap 1.0 on it sometime
in May. Also that I am expecting to have several releases made during
the production of points on this list.
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.
+1
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
+1
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.
overall, yes - the nasty details can be discussed at a later point, hence
+1
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
this assume we do have a server w/ pluggable adapters, no ?
E.g. JPA/JavaEE/Hibernate adapters verus YetAnotherDatabaseThingy adapter
Yeah,
that is something we are lacking in this list is what the
abilities of our server "are".
For the most part I assumed that each step a server technology or spec
was built up and kept up.
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.
Didn't M3 already include 'realtime' ?
For me real time means there is
a persistent connection. If the client
is offline the message fails and there is an error. Also realtime means
that changes made to the client's data are automatically uploaded and
propagated. M3 was only concerning itself with detecting changes of
remote data and notifying the user and possible doing some merging if
there wasn't a conflict.
Also in this step is the ability for the server to send the changes
themselves instead of sending a notification that something changed.
I think of push technologies like a message queue. Deliveries are
eventually made and trusted to get made at some random point in the future.
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.
what about M7? :)
M7 was scared of 8 so it is hiding.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:02 a.m.
On Thu, Jan 30, 2014 at 5:13 PM, Summers Pittman <supittma(a)redhat.com>wrote:
On 01/30/2014 11:03 AM, Matthias Wessendorf wrote:
On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman <supittma(a)redhat.com>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.
ahm... thinking about 2.0.0 before we have a 1.0.0 ? Not sure I
understand that
The point I was trying to make is that I'm not expecting everything on
here to get done quickly from top to bottom and slap 1.0 on it sometime in
May.
Oh, ok - yeah, I totally agree that we should _not_ say: 1.0 is in May and
it contains all the bits from your M1 -> M8;
Also that I am expecting to have several releases made during the
production of points on this list.
yep!
> 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.
>
+1
>
>
> 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
>
+1
>
>
> 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.
>
overall, yes - the nasty details can be discussed at a later point, hence
+1
>
> 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
>
this assume we do have a server w/ pluggable adapters, no ?
E.g. JPA/JavaEE/Hibernate adapters verus YetAnotherDatabaseThingy adapter
Yeah, that is something we are lacking in this list is what the abilities
of our server "are".
that was my thought as well
For the most part I assumed that each step a server technology or spec was
built up and kept up.
I think a 'real' server (w/ adapters) might be needed at some point :-)
>
> 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.
>
Didn't M3 already include 'realtime' ?
For me real time means there is a persistent connection.
same here - but that's listed (real-time) in M3 as well, right ?
If the client is offline the message fails and there is an error. Also
realtime means that changes made to the client's data are
automatically
uploaded and propagated.
+1
M3 was only concerning itself with detecting changes of remote data
and
notifying the user and possible doing some merging if there wasn't a
conflict.
Ah!! ok, did not get that from reading the list
Also in this step is the ability for the server to send the changes
themselves instead of sending a notification that something changed.
agreed
I think of push technologies like a message queue. Deliveries are
eventually made and trusted to get made at some random point in the future.
well, I have some thoughts on that, when we get there :)
>
> 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.
>
what about M7? :)
M7 was scared of 8 so it is hiding.
I hope it was not: buy all the booze for M8 :-)
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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
_______________________________________________
aerogear-dev mailing
listaerogear-dev@lists.jboss.orghttps://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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
2:49 a.m.
On Thu, 30 Jan 2014 11:13:28 -0500
Summers Pittman <supittma(a)redhat.com> wrote:
On 01/30/2014 11:03 AM, Matthias Wessendorf wrote:
>
>
>
> On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman <supittma(a)redhat.com
> <mailto:supittma@redhat.com>> 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.
>
>
> ahm... thinking about 2.0.0 before we have a 1.0.0 ? Not sure I
> understand that
The point I was trying to make is that I'm not expecting everything on
here to get done quickly from top to bottom and slap 1.0 on it sometime
in May. Also that I am expecting to have several releases made during
the production of points on this list.
Yay! That's was exactly my point for QE CI challenges.
1:15 p.m.
On Jan 30, 2014, at 11:03 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman <supittma(a)redhat.com> 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.
ahm... thinking about 2.0.0 before we have a 1.0.0 ? Not sure I understand that
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.
+1
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
+1
somewhat related http://blog.lholmquist.org/img/ab_sync_conflict.jpg
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.
overall, yes - the nasty details can be discussed at a later point, hence
+1
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
this assume we do have a server w/ pluggable adapters, no ?
E.g. JPA/JavaEE/Hibernate adapters verus YetAnotherDatabaseThingy adapter
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.
Didn't M3 already include 'realtime' ?
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.
what about M7? :)
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:24 p.m.
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
3:43 p.m.
On Thu, Jan 30, 2014 at 9:24 PM, Summers Pittman <supittma(a)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(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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
3976
days inactive
3980
days old
8 comments
5 participants
participants (5)
-
Corinne Krych -
Karel Piwko -
Lucas Holmquist -
Matthias Wessendorf -
Summers Pittman