Re: JSON editing and move conflicts

On Wed, Dec 3, 2014 at 1:46 AM, Alex North wrote: > > > Joseph's earlier comments suggest you already realise this, but Wave > implements map structures as list-of-pairs, so conflicting operations end > up both surviving at the protocol level, with a consistent order reflecting > their server ord

Re: JSON editing and move conflicts

Joseph's earlier comments suggest you already realise this, but Wave implements map structures as list-of-pairs, so conflicting operations end up both surviving at the protocol level, with a consistent order reflecting their server order, so that conflict resolution can be left to the application

Re: JSON editing and move conflicts

On Wed, Oct 22, 2014 at 2:50 AM, Patrick Coleman wrote: >> >> - I'm not sure if I want to make this OT type invertable. If we don't, > > What are the costs of making it invertable? i.e. are there particular > reasons not to? > I guess for proper invertability, you'd need to copy all the data being

Re: JSON editing and move conflicts

> > - I'm not sure if I want to make this OT type invertable. If we don't, finding the data that was actually deleted will be difficult > What are the costs of making it invertable? i.e. are there particular reasons not to? I guess for proper invertability, you'd need to copy all the data being m

Re: JSON editing and move conflicts

Good thought, although I don't think there's much stopping you doing that today. Unless I'm missing something, 3d scenes are mostly a set of objects (meshes). You can store that in a list just fine. If you want a scenegraph, you have the same use case as a collaboratively editable DOM - which is,

Re: JSON editing and move conflicts

The more we discuss this, the more I'm becoming convinced that the right answer is to transform the operations to something that will be recoverable by the application. The easiest way to do this is to move the otherwise deleted data to some recovery area (a list). The application can issue a subse

Re: JSON editing and move conflicts

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 t

Re: JSON editing and move conflicts

> > 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 t

Re: JSON editing and move conflicts

challenges. > > ~Michael > > From: Richard Davis > Reply-To: > Date: Monday, October 20, 2014 at 6:53 PM > To: > Cc: , > Subject: Re: JSON editing and move conflicts > > Hi Joseph, > > Regarding object move, I'm in favor of keeping things simple, but I&

Re: JSON editing and move conflicts

: Date: Monday, October 20, 2014 at 6:53 PM To: Cc: , Subject: Re: JSON editing and move conflicts Hi Joseph, 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

Re: JSON editing and move conflicts

Hi Joseph, 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 s

Re: JSON editing and move conflicts

On Sun, Oct 19, 2014 at 3:35 AM, Bruno Gonzalez (aka stenyak) wrote: > Renamed keys for user-facing dicts, and application lambdas for > user-hidden dicts sounds reasonable to me. > > What about different lambdas affecting each other while they run? E.g. > two client-side lambdas trying to solve t

Re: JSON editing and move conflicts

Bruno, Using lists of lists alleviates of the issues that Joseph mentions with object properties. With nested list there are safe and easy ways to handle these types of conflicts since we can increment array indices with predictable and non-destructive outcomes. You point about lambdas is correc

Re: JSON editing and move conflicts

Joseph Gentle, did you see *rfc6902 *JavaScript Object Notation (JSON) Patch specification ? Do you plan you add OT for this spec in livedb? On Sunday, October 19, 2014 4:46:11 AM UTC+4, Joseph Gentle wrote: > > It does complicate the type, and it

Re: JSON editing and move conflicts

Renamed keys for user-facing dicts, and application lambdas for user-hidden dicts sounds reasonable to me. What about different lambdas affecting each other while they run? E.g. two client-side lambdas trying to solve the same conflict. Or also, since lambdas can potentially do *anything* in t

Re: JSON editing and move conflicts

It does complicate the type, and it breaks my nice abstraction. Also remember that any funny logic will need to be on the server and the client - and I'd really like the server to be application-agnostic if possible. That said, the server will probably need application-specific schema validation &

Re: JSON editing and move conflicts

Hi Joseph, I think that the only sensible option is to delegate the resolution of this action in the case of conflict back into the application, so some sort of extension of (4) that allows some arbitrary lambda expression to be passed as the onconflict method. (Depending on the situation, they mi