On 01/28/2014 11:44 AM, Matthias Wessendorf wrote:
On Tue, Jan 28, 2014 at 4:30 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
On 01/28/2014 09:36 AM, Lucas Holmquist wrote:
> yup, this is another Data Sync thread,
>
> >From a client side perspective, i have concerns that there is
still not a clear direction yet.
>
> I know there are multiple ideas floating around on what our
model should be, i'm all for choice, but what about deciding on 1
model to get started with. Then later once we have this nailed
down, we can have other "adapters" with different models perhaps
All the data model is is an envelope of sync metadata around an object
right?
We also need to think about the API and server/client protocol as
well.
I think that for sync 1.0 we could focus on the following behavior (it
worked for my demos at least)
1. We have a Sync factory similar to Pipeline, Authenticator,
Registrar, and KeyService.
2. The Sync factory consumes/manages Synchronizer instances.
3. AG Synchronizer listens for sync messages using UnifiedPush
endpoints.
W/ "sync message" you mean something like a 'heads-up' from the server
it has something new, instead of the concrete delta/diff ?
4. AG Synchronizer sends sync messages using Pipes
Like: "server, my local copy changed!" ?
Or, more specifically,
"Here is new data"
5. AG Synchronizer holds local data in a store
6. When AGSynchronizer gets a message it is responsible for updating
the Store and then notifying code listing for updates OR for notifying
the code that an error has occurred and needs to be addressed.
7. When the developer updates data in the store, the synchronizer
should package that data and send it to the server. The
synchronizer is
responsible for error handling, retrying, back-off, etc.
8. We should include multiple synchronizer implementations to
deal with
multiple very simple use cases which involve legacy systems. (For
instance polling to load static data on a schedule.)
Thoughts? Tomatoes?
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
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