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

[Erik Jan de Wit]

That is what I suggested, but then at the same time connect that to pipes and stores, but we can start even simpler and first develop something like this.

On 11 Dec,2013, at 10:37 , 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131211/173eff6d/attachment-0001.html