latos / wave-protocol

Automatically exported from code.google.com/p/wave-protocol
0 stars 0 forks source link

Simultaneous first-time reading of the same conversation by the same user has race conditions #174

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
[Theoretical, never done in practice]
1. Create a wave with several blips, add participant X.
2. User X logs in to two clients, then goes offline (e.g. disconnect network).
3. X opens the wave on both clients, reads some blips in one client, reads 
other blips in the other client.
4. X goes back online on both clients.

What is the expected output? What do you see instead?

Expected output (ideally) is that the reading actions merge concurrently.  e.g. 
any blip read on either client becomes read on both clients.  Each client 
should display this resolution live, without either client needing to re-open 
or refresh.  Additionally, re-open or refresh should be a no-op after this 
resolution: all read-state should be the same.

Instead, theoretically, both clients will have no change on reconnection, but 
when re-opening that wave, the reading actions from only one of the two clients 
will be preserved.

The bug is simple: the embedding of WaveletReadState objects in the m/read 
documetn does not resolve multiple <wavelet> elements with the same id.

A fix for this must preserve the cleanup-on-write property.  i.e., active 
resolution of the XML, by merging the data in the XML as soon as duplicates are 
observed, is not acceptable.  This makes a fix not completely trivial.

Since the data types embedded inside each per-wavelet read-state object element 
are monotonic and superimposable, one solution is for WaveletBasedSupplement to 
collect all WaveletReadState objects that exist for the same id, and wrap them 
in a composite WaveletReadState object, that distributes all queries over each 
component read state object.  On any write subsequent action, for any wavelet 
with multiple <wavelet> elements, a new <wavelet> object can be added that 
contains the sum information of all the others, and then all the original 
<wavelet> elements can be deleted.

Doing this completely correctly, with respect to composition, intermediate 
transitive states, left-to-right broadcast of document events, and a sensible 
resolution of multiple WaveletReadState objects, may or may not be difficult.

Original issue reported on code.google.com by david.he...@gmail.com on 2 Dec 2010 at 5:12