[aerogear-dev] Data Sync braindump

[Sebastien Blanc]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131203/eff8e347/attachment.html