9:21 p.m.
Howdy!
Since we're starting the data-sync sprint, I'd like to bring some of the
ideas that born from the research I've been doing.
Note that those are only ideas that will be validated by a PoC or
something like this (which I'm planning to continue working on after I'm
back from PTO)
I envision a layered approach:
1) CouchDB Sync Protocol
This is an approach that I really like a lot - it has lots of common
things with git (keeping SHAs of the document's state and history of
changes (until you compact your history)). The main advantage is that we
can re-use all the nice algorithms we already have on the git lands to
solve conflicts.
2) OT/EC
This is really nice & well-known, but I think it would apply better for
individual fields into a document.
3) Crypto signatures
We could have ed25519 signatures on the changes, making it potentially
safer to decide who should win a change conflict based on rules that
goes beyond simple merging strategies (business roles?)
All this 3 layers could live on top of a very simple JSON protocol,
which would allow us to evolve it gradually (I know this is prone to not
be super efficient, but I don't want to optimize prematurely, and JSON
compresses really well)
Thoughts?
Don't forget to read Summer's thread on this. (can someone reply with
the link?)
--
qmx
2:39 a.m.
Thanks Qmx for starting this thread.
Here the link to Summer's thread :
http://lists.jboss.org/pipermail/aerogear-dev/2013-March/002090.html
On Tue, Dec 3, 2013 at 3:21 AM, Douglas Campos <qmx(a)qmx.me> wrote:
Howdy!
Since we're starting the data-sync sprint, I'd like to bring some of the
ideas that born from the research I've been doing.
Note that those are only ideas that will be validated by a PoC or
something like this (which I'm planning to continue working on after I'm
back from PTO)
I envision a layered approach:
1) CouchDB Sync Protocol
This is an approach that I really like a lot - it has lots of common
things with git (keeping SHAs of the document's state and history of
changes (until you compact your history)). The main advantage is that we
can re-use all the nice algorithms we already have on the git lands to
solve conflicts.
2) OT/EC
This is really nice & well-known, but I think it would apply better for
individual fields into a document.
3) Crypto signatures
We could have ed25519 signatures on the changes, making it potentially
safer to decide who should win a change conflict based on rules that
goes beyond simple merging strategies (business roles?)
All this 3 layers could live on top of a very simple JSON protocol,
which would allow us to evolve it gradually (I know this is prone to not
be super efficient, but I don't want to optimize prematurely, and JSON
compresses really well)
Thoughts?
Don't forget to read Summer's thread on this. (can someone reply with
the link?)
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:37 a.m.
Hi,
I like the topic of this thread so just wanted to add my 2 cents. As you know when I was
with Errai we have implemented operation transforms and data sync and we have had a lot of
discussions around these.
OT/EC is really nice, but it's a totally different use case then offline sync. The
idea is that you only send your operations something like Insert[0, "x"] meaning
on position 0 insert a x as you can see this will only work well if you have a very
current version of the document that you are editing.
The sync from Errai is based on JPA and does merging based upon fields in the Entity on
the server. By doing this the chance of conflicts is smaller but still there can be
conflicts and those must be handled by a user. So we need to build a way to sent the
different states back to the user.
We could also create something that does a peer to peer sync (eliminating the need for a
central server) couchDB has a protocol that does that I think. Maybe we should think of
use cases that we want to support like in Summer's thread and maybe we need more then
one solution.
Cheers,
Erik Jan
On 3 Dec,2013, at 8:39 , Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
Thanks Qmx for starting this thread.
Here the link to Summer's thread :
http://lists.jboss.org/pipermail/aerogear-dev/2013-March/002090.html
On Tue, Dec 3, 2013 at 3:21 AM, Douglas Campos <qmx(a)qmx.me> wrote:
Howdy!
Since we're starting the data-sync sprint, I'd like to bring some of the
ideas that born from the research I've been doing.
Note that those are only ideas that will be validated by a PoC or
something like this (which I'm planning to continue working on after I'm
back from PTO)
I envision a layered approach:
1) CouchDB Sync Protocol
This is an approach that I really like a lot - it has lots of common
things with git (keeping SHAs of the document's state and history of
changes (until you compact your history)). The main advantage is that we
can re-use all the nice algorithms we already have on the git lands to
solve conflicts.
2) OT/EC
This is really nice & well-known, but I think it would apply better for
individual fields into a document.
3) Crypto signatures
We could have ed25519 signatures on the changes, making it potentially
safer to decide who should win a change conflict based on rules that
goes beyond simple merging strategies (business roles?)
All this 3 layers could live on top of a very simple JSON protocol,
which would allow us to evolve it gradually (I know this is prone to not
be super efficient, but I don't want to optimize prematurely, and JSON
compresses really well)
Thoughts?
Don't forget to read Summer's thread on this. (can someone reply with
the link?)
--
qmx
_______________________________________________
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
6:32 a.m.
My 2 cents here, ed25519 is the best choice and we could do it with kalium
(https://github.com/abstractj/kalium), but that would require the installation of C
library, IMO a drawback. Another alternative would be to implement ed25519 on top of
ECDSA, because the only curves supported by BouncyCastle are
http://www.bouncycastle.org/wiki/display/JA1/Supported+Curves+(ECDSA+and+....
So my suggestion is: start simple with the curves supported by BC, slow or not. Improve
later.
On December 3, 2013 at 12:21:41 AM, Douglas Campos (qmx(a)qmx.me) wrote:
3) Crypto signatures
We could have ed25519 signatures on the changes, making it potentially
safer to decide who should win a change conflict based on rules that
goes beyond simple merging strategies (business roles?)
--
abstractj
7:02 a.m.
Hi, the following branch was started to track the ideas about data sync and goals to the
next release: https://github.com/aerogear/aerogear.org/tree/data-sync
On December 3, 2013 at 5:39:10 AM, Sebastien Blanc (scm.blanc(a)gmail.com) wrote:
Thanks Qmx for starting this thread.
Here the link to Summer's thread :
http://lists.jboss.org/pipermail/aerogear-dev/2013-March/002090.html
--
abstractj
3801
days inactive
3801
days old
4 comments
4 participants
participants (4)
-
Bruno Oliveira -
Douglas Campos -
Erik Jan de Wit -
Sebastien Blanc