Good morning Summers, it sounds like a fancy good idea. Out of curiosity do you know where
such method was applied for real?
Not advocating in favor of CouchDB, but might be interesting to look at:
http://wiki.apache.org/couchdb/Replication_and_conflicts and
http://guide.couchdb.org/draft/consistency.html#figure/6.
One open question still in my mind. For the server side bits. Why not just make use of a
provider? For example on SPS for data stores Dan have implemented something like
this: https://github.com/aerogear/aerogear-simplepush-server/tree/master/...
ps: I’m not against us implementing anything new.
--
abstractj
On January 8, 2014 at 7:07:40 PM, Summers Pittman (supittma(a)redhat.com) wrote:
So I'm not sure I see how the data model in the current sync spec
helps
with syncing data. Also the current spec draft is lacking a transport
format as well.
I propose using the dual shadow data model described here:
https://neil.fraser.name/writing/sync/
## Data Model: and Transport:
Client side each piece of data which is currently in active
synchronization (ie the client is sending AND receiving updates
at the
same time) has a copy of her data which represents the current
assumed
good synchronized state. She also has the copy of the data she
is
editing. When she has finished her edit (for an use case specific
defined by the developer definition of finish) the system will
generate
a diff based on the JSON representations of her shadow and her
model.
The model will replace the shadow and a diff of her data as well
as a
checksum of her data will be sent to the server for processing.
Server side the server will maintain its own model of the shared
data,
as well as shadows for each session currently sync the data. When
it
receives a sync, the diff will be applied to the server's shadow
of the
session which sent the diff. If the diff merges cleanly and the
checksum of the server shadow matches the checksum in the transport,
then the server will update the canonical model of the data against
what
was in the session's updated shadow. The server will then diff
all of
its sessions' shadows against its model and send out diff messages
to
the clients.
I've made a spreadsheet* where I follow one of QMX's sample applications
and step through a few workflows with my proposed data model.
(This is
the data model I use in the DevNexus sync demo and the real time
text
demo). I would welcome someone to implement the use case with
QMX's
proposed data model.
*
https://docs.google.com/spreadsheet/ccc?key=0AjSy-Z4v4qE-dGhESFU5R1BSWTF3...
wdyt? Who would mind doing the data flow for the other model?
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev