bigeasy / addendum / 38 / 1

100%

master: 100%

push

travis-ci

Arrival and acclimation.

All applications are going to use the atomic log to make changes to
common set of data. If they all start with the same data and then make
the same changes in the same order, then after each change they will
have the same data that all their peers had when they made the
change.

This is called a replicated state machine. Each "machine" makes the same
changes to a data set so that each "machine" has the same "state."

The machine in our case is our `Addendum` object. The state changing
events will be the postbacks from Compassion which will arrive in the
same order for all participants.

The original participant will create the init with an initial data set.
There is a `bootstrap` event that we can respond to that will only be
invoked if the participant is the very first participant. The
bootstrapped participant can use this perform any initialization to the
data set. We don't need to respond to this event because out empty
database is simply an empty object used as a map.

Subsequent participants can receive a `join` event. We use the join
event in Addendum to fetch a copy of the database from one of the other
participants. It can't be just any copy. It can't be, say, the current
copy that any other participant has on hand. It must be the database
exactly as it was when we arrived, without any modifications made after
the participant arrive and not omitting any modifications made before it
arrived.

We use the `arrive` event to freeze a copy of the database when a new
participant arrives into a Cubbyhole. We will use that frozen copy of
the database specific to the promise (event id) of the participant's
arrival should the participant choose us when it asks for a copy of the
database when it joins.

This is a common operation, getting a backlog of work, or a snapshot of
work (hmm… maybe rename the postback from backlog to snapshot). An
Addendum participant makes its frozen copy of the database available
using the backlog post... (continued)

0 of 4 branches covered (0.0%)

48 of 60 relevant lines covered (80.0%)

1.73 hits per line