2 v2

crucially # can I do conflict resolution in post commit hooks?

seancribbs # crucially: i don't think so

crucially # pre commit hooks? i guess I could from erlang

crucially # if you set returnbody and I set the content type to multipart and 
there is a conflict, i am supposed to get all siblings?

justinsheehy # you can do some conflict resolution, but you can't easily guarantee 
that a get won't have siblings, as there isn't an assumption of atomicity there. 
that is, another such put (with its postcommit hook) may be running concurrently.

crucially # right, but then I will get another conflict?

justinsheehy # crucially: it depends. 2 answers...
1 - your conflict resolution could spawn off a fresh put in case of conflict, 
in a way that would continue to recurse indefinitely until no conflict occurred.
2 - that'd catch most cases, but not the operational failure case where a partition 
has allowed conflicts to not be visible at write time (node A and node B both 
accepting writes but not reaching each other)
due to that situation, you can't 100% guarantee to _never_ have siblings at 
read time (without simply having one of them "win", of course)
but you could come very close


crucially # justinsheehy: i still expect to have to do it in read

justinsheehy # then you're good

crucially # but i can't fire off a put from javascript?


justinsheehy # not currently, no. js->erlang upcalls are tricky. on the 
"we want to do it" list, but not in a planned iteration.