Sorry to bump in here, but another potential use case of Json syncing eventually could be for 3d collaboration. If multiple people could work of a 3d scene based on Json data (as webGL can be: http://www.lighthouse3d.com/2013/07/webgl-importing-a-json-formatted-3d-model/ ) , it should be possible to make a ShareJS based collaborative 3d environment - which itself then has other interesting possibilities in turn. This is only vague thinking at the moment , but might be worth baring in mind.
~~~ Thomas & Bertines online review show: http://randomreviewshow.com/index.html Try it! You might even feel ambivalent about it :) On 21 October 2014 10:49, Patrick Coleman <patcole...@google.com> wrote: > > > > My worry is that if someone else moves another file called rope.h to > > the resources directory at the same time, I don't want the result to > > ever be that one of our files gets deleted from disk. > > > > If the client/server keeps recent operations in memory and supports undo / > has their own logic to recognize and handle move collisions, this seems > less of a problem. > > Alternatively, are any tests supported? (like in 6902 > <https://tools.ietf.org/html/rfc6902#appendix-A.8>) > in which case each move could include a test that the original value is > missing, and so would automatically be undone when transformed against an > identical move. > > > Some observations: > > - This will almost never actually happen in real life. > > - Even if we turn the operation will transform into a 'replace', we > > could add a flag to the operation to mark that it was unintentionally > > overwritten, and then the process which is making the corresponding > > changes on disk could see that and do some special > > application-specific behaviour instead of actually deleting the file. > > > Indeed - your structure could instead be: > { "name": "librope", > "package": { > "src": { > "rope.c": "somelonguniqueid", > "rope.h": "anotherfileid", > }}, > data: { > "somelonguniqueid": { "text": "#include <rope.h>\n ..." }, > "anotherfileid": { "text": "// This is a cool header" }, > }} > > Then deletion is some separate offline index/cleanup, and resolving > conflicts is simpler. > (although 'move' is less useful here as there are no child properties). > > > > > > > Regarding object move, I'm in favor of keeping things simple, but I'm > > also > > > in favor of thinking about this in terms of what people might actually > do > > > with this capability. Since mapping a directory structure of files is > the > > > one good example you have, then maybe multiple moves to the same key > > should > > > merge their values as directory moves merge their files. That would > mean > > a > > > slightly modified version of your option 1. In the simple case, you > have > > > {x:1, y:2} -> {z:2}, but in the complex case you have {x:{a:1}, > y:{b:2}} > > -> > > > {z:{a:1, b:2}}. > > > > Does move distinguish between PUT vs. PATCH? > I would assume PUT (x: {a: 1}) -> z and PUT (y: {b: 2}) -> z would end up > in z: {b:2} > but if the second operation received was a PATCH operation, they would be > merged rather than replaced. > For file system moves they'd probably be PUT, but their might be instances > where a PATCH is useful. >
