Hi,
Really interesting. I'm also thinking a lot about the data synch process and I'm glad to see that your ideas are pretty much the same as me.
But great challenges to come like dealing multiple edits of the same record by different clients :)
About triggering the synch process we could start a POC with the "online" event on the client side, that could spawn a webwork script taking care of the synch process. 
On the server side, we have to manage a sort of queue maintaining the state of the "dirty" records on which the clients can subscribe (and being noticed by push events , web sockets etc ...) , very exciting stuff to come.

Seb
Envoyé de mon iPhone

Le Oct 10, 2012 à 17:31, Kris Borchers <kris@redhat.com> a écrit :

Hey all,

Just wanted to let you know what I am working on right now. It is very early but Matthias loves e-mail so I thought I would throw this out there.

Basically, right now all I am doing is working on keeping track of the status of data in DataManager. Assuming a new dataSync setting is set to true, these are the things I am planning.

  • New record is added to store, status is set to NEW and a UUID is generated
  • Record is updated, status is set to MODIFIED
  • Record is removed, status is set to REMOVED (data is not actually removed, future will need to keep storage limits in mind)
  • Add a new sync method that will run through the data and sync with the server. Assumes client is data of record for now during development until we can determine a strategy for informing the client how the server tracks data status and how it should be informed that this data is being synced
    • This brings us back to the discussion about sending metadata to the client on first app load. That metadata could inform the client of the sync strategy

There's probably more to this but these are my original thoughts right now.

Kris
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev