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 might want to 'merge' the two items (if possible), rather than
moving one into a 'backup' location).
This does complicate the OT type, and does make it more difficult to
analyse how long certain actions will take to resolve though...
How does this sound?
Ali
On 19 October 2014 00:33, Joseph Gentle <jose...@gmail.com> wrote:
> I'm (finally!) taking a serious look at making a better version of the
> JSON OT type. I'm cross-posting this here because it directly effects
> sharejs & derby users, and I think any serious rewrite of wave will
> use something like this at the top level to store waves.
>
> I have two questions that I would love some input on from the wider community.
>
> We want to add a 'move' action which will let you transplant arbitrary
> parts of the JSON structure to other places in the tree. This is
> really useful if, for example, you want a hierarchal to-do list, a
> tree of source files for your IDE or a tree of blips.
>
> But I can't figure out what should happen if two users move different
> objects to the same place in the tree at the same time.
>
> 1. The simplest option is to simply delete one of them. This is really
> convenient from a programming pov, but I think that would be the worst
> kind of surprise. {x:1, y:2} -> {z:2}
> 2. We could try and make one of the moves fail - {x:1, y:2} -> {x:1,
> z:2}. On the face of it this sounds great, but this is a cascading
> failure. If (locally) I move x->z then insert some new data at x, what
> happens to the new data? Does the new data get deleted? Does x get
> deleted? I can't think of a good answer here which isn't just
> dangerous in a more complicated way. Making both the moves fail has
> the same problem.
> 3. We could pick a winner and then move the loser to some special
> lost&found bucket or something. So, {x:1, y:2} -> {__recovered_z:1,
> z:2} But that could play havoc with data bindings, and we'd have to
> introduce some reserved keys. The other way to do this is to introduce
> a new top-level structure which contains the data, so it'd be
> {data:{x:1, y:2}} -> {data:{z:2}, lost:[{z:1}]}.
> 4. Or we could add the backup location into the move operation itself,
> so whoever's building on top of this API can make the choice. (They
> can make a better decision because they know what the data structure
> looks like). So instead of (move x->z) we'd have (move x->z,
> onconflict:(move x->__x)) or something.
>
> Are there any other choices I'm missing here? I'm edging toward option
> 4, although it might increase the type's complexity by 50% unless I
> can think of a clean way to do it.
>
> Thanks
> -J
