incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Gentle <>
Subject Re: JSON editing and move conflicts
Date Mon, 20 Oct 2014 17:16:55 GMT
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 the same conflict. Or also,
> since lambdas can potentially do *anything* in the json data,
> server-side lambdas may affect other concurrent lambdas that weren't
> even working on the very same conflict. Would a global conflict lock be
> used to prevent it, or is there any strategy to guarantee these issues
> won't happen?

I don't think so. And remember, these lambdas will need to run on both
the client and the server, and they need to produce the exact same
result. Preferably they should do that without access to the document
itself. (In all other cases transform doesn't need access to the
document itself, and the document isn't passed in).

A conflict lock here is the wrong tool. It'd add way more complexity
than I'm comfortable with to solve this problem. Also the point of OT
that you don't need locks.

> I'm assuming ditching json for a simpler format (just lists of lists),
> delegating dictionary implementation to each application, is either a
> dumb idea, or just another variant of same original problem (since I
> guess we would end up providing a dictionary emulation library using
> lists of (key,value) lists anyway, which applications may or may not
> use, so exactly like current situation with lists and dicts).

Yeah - thats what I'm worried about. Overwrite semantics are only
dangerous for non-unique keys. ... but they are basically always the
wrong outcome when someone does a move operation.


View raw message