This proposal does present one solution to a problem I hadn't yet resolved
which was how to deal efficiently with the commit notice and acknowledgement
data. Logically the data is represented as records with four fields
(Destination name, WaveletName, last acknowledged version, last committed
version). Another way to look at is as a sparse table where the first two
columns are WaveletName and last committed version and the remaining columns
contain the last acknowledged version for a given name, one name per column.
I think it's possible to generate checkpoints from the DeltaStore without
too much change. For the fileDeltaStore, the DeltaAccess implementation
would append a (WaveletName, start version, end version) record to a file
(at the root of the store), and an timer job (triggered by the first log
append) would suck in all the records, merge them and generate a checkpoint.
This would allow the DeltaStore to generate checkpoints without the need to
change it's existing interface and only minor changes to it's
implementation.
I'm assuming that SignedVersion is actually HashedVersion. And that the
structure of CheckPoint a sequence of triples {wavelet name, start version,
end version}). I'm also assuming that CheckpointId's have a natural order
and monotonically increase.
I think some of the details of the interfaces need to be changed but
fundamentally it seems like an appropriate solution for WiaB.
-Tad
On Thu, Dec 16, 2010 at 1:59 PM, Alex North <[email protected]> wrote:
> Oops, thanks, I had hotlinked a non-internet-accessible images.
>
> Also +wave-dev
>
>
> On 17 December 2010 02:14, Tad Glines <[email protected]> wrote:
>
>> The image is broken.
>>
>> On Wed, Dec 15, 2010 at 9:51 PM, Alex North <[email protected]> wrote:
>>
>>> Prompted by Tad's proposal for commit notification persistence I've got
>>> around to publishing a design we had in Google Wave, and were part way
>>> through implementing (we can probably open the code) for a recovery service
>>> based on checkpoint messages.
>>>
>>>
>>> https://sites.google.com/a/waveprotocol.org/wave-protocol/protocol/design-proposals/checkpoint-based-recovery
>>>
>>> This has many similarities with Tad's proposal and aims to solve the same
>>> problems. Note that this design was originally for Google Wave, and Wave in
>>> a Box may support an even simpler design to start. This is a good
>>> opportunity to review the design (though since there is existing code this
>>> may be a good place to start).
>>>
>>> Alex
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Wave Protocol" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected]<wave-protocol%[email protected]>
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/wave-protocol?hl=en.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Wave Protocol" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<wave-protocol%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/wave-protocol?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Wave Protocol" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<wave-protocol%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/wave-protocol?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "Wave
Protocol" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.
