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@redhat.com> wrote:
>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.
> Just because I want to start with a simple use case doesn't mean you can
> dismiss the use case.
>
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev