[aerogear-dev] how about this API for sync?

[Corinne Krych]

Hi all,

Here's my view:

Different options at different levels. Some options are corellated.

SyncManager: when to trigger:
1. periodically
2. automatic: online/offline detection
3. manually

Server vs peer-to-peer context
1. server context with revision tag, client send his updates, conflict resolution server side
2. no prior context :
http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p218.pdf
 - queing push
 - pull

Granularity
1. Document based. revision at object/fields level.
2. OT

Conflicts resolution:
1. reject
2. proposed merge 
3. prompt user


Like Dan, I think we could have several implementations of sync depending on the use cases and let the end user (developer) picks the right one ffor the job. 

But we need to start with one of them,  simplest one would be:
- manual trigger sync
- server side context with revision number
- offline caching
- client send his updates
- server conflicts resolution with rejection of client changes

++
Corinne


On Dec 11, 2013, at 10:37 AM, Daniel Bevenius <daniel.bevenius at gmail.com> wrote:

> First, I appreciate the discussion in this thread as this is all new to me.
> 
> > What use cases should we support first?
> I'd be for looking into the document use case first, and hold off with the transactional/Operational Transformation one for now. This mainly because is seems to be a lot simpler. 
> 
> qmx suggested using something similar to CouchDB. CouchDB uses a revision field for each document to handle/detect conflicts. 
> The following is a concrete example of how this works with CouchDB:
> 
> Create a database:
> curl -X PUT http://127.0.0.1:5984/agsync
> {"ok":true}
> 
> Get a uuid:
> curl -X GET http://127.0.0.1:5984/_uuids
> {"uuids":["f11075199bcea80849204660d7000d53"]}
> 
> Create a car object(document) using the above uuid:
> curl -X PUT http://127.0.0.1:5984/agsync/f11075199bcea80849204660d7000d53 -d '{"car": {"make":"Toyota", "color":"red"}}'
> {"ok":true,"id":"f11075199bcea80849204660d7000d53","rev":"1-dffbd1dbd1b9ecbffc1b02a34cbaea0b"}
> 
> Notice that the server returned a new document revision.
> 
> Now clientA updates the car object, notice that we are specifying the document revision:
> curl -X PUT http://127.0.0.1:5984/agsync/f11075199bcea80849204660d7000d53 -d '{"_rev":"1-dffbd1dbd1b9ecbffc1b02a34cbaea0b", "car": {"make":"Toyota","color":"blue"}}'
> {"ok":true,"id":"f11075199bcea80849204660d7000d53","rev":"2-588a9da2e252e9a3d2fc0634610a0c25"}
> 
> Also, notice how the server returned a new document revision.
> 
> Now, clientB still has the old revision and tries to update the car object:
>  curl -v -X PUT http://127.0.0.1:5984/agsync/f11075199bcea80849204660d7000d53 -d '{"_rev":"1-dffbd1dbd1b9ecbffc1b02a34cbaea0b", "car": {"make":"Toyota","color":"yellow"}}'
> < HTTP/1.1 409 Conflict
> {"error":"conflict","reason":"Document update conflict."}
> This conflict would the have to be handled by the client. Could we start out with something similar and as simple as this and evolve it?  
> 
> 
> 
> On 11 December 2013 08:30, Erik Jan de Wit <edewit at redhat.com> wrote:
> >
> > Just because I want to start with a simple use case doesn't mean you can
> > dismiss the use case.
> >
> 
> 
> I don’t want to dismiss anything just wanted to know what you think about my idea to combine a pipe and store to create a pipe that continues to work when the user goes offline. Obviously you don’t feel my idea makes any sense and I think that you sync isn’t a super powerful feature to have (there are to many pre conditions in my opinion), but we could have it, not dismissing it.
> 
> What do others think about this discussion? What use cases should we support first? Can you think of other ways/things to sync?
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev