search

ericmckean / wave-protocol

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

Wavelet deltas consolidation-treshold attribute #18

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
I propose to have a consolidation-threshold (xsd:integer) attribute on 
wavelet so "older" Delta operations (MutateDocument) must be consolidated 
on server side once this threshold have been reach, so only deltas in 
range "last Delta operation *less* consolidation-threshold" are accesible 
for "activity history" on wavelet, olders would be see as a "unique Delta-
>operation->MutateDocument->characters"

Also I propose to apply Threshold not on real-time OT but to be applied 
applied only when wavelet fall to serialization state on sever, (no active 
sessions on wavelet for C2S and/or no OT concurring at that point on 
wavelet on federation scenario)

All severs known consolidation-threshold value so them can apply when 
appropiate wihtout further payload.

Original issue reported on code.google.com by jesus.sa...@gmail.com on 25 Jun 2009 at 9:31

GoogleCodeExporter commented 9 years ago

Original comment by btkalman@gmail.com on 29 Aug 2009 at 2:10

GoogleCodeExporter commented 9 years ago 
The problem here is that this would mess up both signing and playback. The 
former is a 
more severe issue.

Original comment by anthonybaxter@gmail.com on 16 Mar 2010 at 4:16

GoogleCodeExporter commented 9 years ago 
I think there is a way to "compress" the history of a wavelet without 
compromising on
security and still allowing for the possibility of playback.
Let's say that a wavelet host want's to create a "composite" history element 
for the
version 0 through 1000. The host would sent a "get signature for composite" 
request
to all wavelet remotes for which there was a contributing participant within 
that
history range. Each remote would construct a "wavelet state at version 1000" 
delta
that a sequence of add-participant operations (sorted by participant id), 
followed by
a set of document operations (sorted by document id). Then it would sign the 
result
and send the signature back to the host.

The host would follow the same process as the remotes and would verify each of 
the
signatures. If all signatures are collected and verified, then it would add a
"composite" history that is a ProtocolSignedDelta containing the delta as 
constructed
above, plus all the signatures.

Then, when a new remote see's a delta or commit notice for the first time, it 
could
ask for the most recent "composite" plus history that follows. Then, if a client
requests history earlier than the "composite", or a delta arrives with a target
version earlier than the "composite", the remote could request the needed 
earlier
history elements.

The only way for the "composite" element to be different from what it should be 
is if
the wavelet host conspires to make it so (perhaps by only including it's own
signature). But, this is easily verifiable, by requesting the full history.

For wavelets with a very large history, this could result in a significant
improvement in loading delay, especially for slower clients.

Original comment by Tad.Glines@gmail.com on 16 Mar 2010 at 4:50

GoogleCodeExporter commented 9 years ago 
It's possible that this would work. It'd be a significant amount of new work, 
and 
we're not likely to get to it any time soon.

Original comment by anthonybaxter@gmail.com on 18 Mar 2010 at 12:39

GoogleCodeExporter commented 9 years ago

Original comment by joe.gregorio@gmail.com on 18 Mar 2010 at 12:49