I don't want to cut this section, because the points that it makes are
important ... but those points aren't a good fit for the purposes of this
document. If someone needs some examples of why badly managed chain
replication can lose data, this is the section to look in. ^_^
All of the major surgery required to move Chain Manager design & discussion
details out of the high-level-machi.tex document are complete. I've done
only a very small amount of work on the original high-level-machi.tex to
fix document flow problems.
There's probably a good way to have LaTeX automatically manage the
mutual references between the now-split documents, but I didn't know about,
sorry.
Major changes, when compared to the original Basho-internal document:
* Start removing strong consistency topics to a separate doc (unfinished)
* Remove section on per-file metadata management: it was too speculative IMHO
* Remove the following sections (numbering is relative to v3 of internal doc):
7.2.1 scenario 1, 13.3, 14
* Move the "Recommended Reading" section to the end
It's Friday, so this is an end-of-week merge. This week has focused
on the chain manager. I ended up doing more refactoring than I'd
expected in order to lift it out of it's "one node, talk to everything
by distributed Erlang, run inside a not-quite-PULSE-but-still-quite-
restricted simulator" and into some OTP sunlight + communicate by
generic point-to-point TCP connections (same ASCII protocol as
demo day, no change there) + capable of running without all of the
simulator control.
I'm happy to say that it appears to work as well as it does inside
of the simulator. Having said that, the branch of experimental
work that I chose to integrate has some problems making transitions
when asymmetric network splits happen. But those appear fixable.
Next week. ^_^
This finishes the first stage of making an OTP-style application
out of the `prototype/demo-day` code. The process structure is not
fully OTP compliant. I'm not sure if I really want it to be 100%
OTP style, but that decision can be deferred for a little while
yet.
There are probably "bugs" with brick shutdown, such as process
leaks. That ought to be fixed someday. The use of the Erlang process
registry for finding writer/sequencer processes is nifty (for a
quick hack), but it also leaks atoms (not good for long-term use).
