On Sun, Oct 19, 2014 at 3:35 AM, Bruno Gonzalez (aka stenyak) <sten...@stenyak.com> 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. -J
