Comments from the 'Bear@Wantage' Presentation
=============================================

1. Where to store the list of schemas? The registry?
	- currently stored in a flat file, distributed to each site

2. Why not start every new schema as a slave, to aid synchronisation?
	- yes, could do this by modifying the id number of the starting
	schema to be a very high number, this would then talk to the master
	to get a copy of its state to synchronise. Id number is then reset to
	real value and election is called to elect new master.

3. Steve F. worried about fragmented networks (sub-nets) with one master
for each net.
   - Could use a quorum of nodes during election to choose the master so
   election process can detect whether nodes are missing (possibly due
   to fragmentation in the network). Merging subnets is, of course, well
   understood, so an algorithm from this prior work will sort out the
   election if more than 1 master exists.

4. For extra stability, use a transactional model to acknowledge all
updates and synchronisations.
   - expensive on processing but probably worth doing for the schema due
   to the small workload on the schema.

5. For updates could also agree on a quorum of receipts to ensure that
the updates stands, otherwise backout the update and try again.