Block Locking

As mentioned above, one detailed requirement is to lock a block so that only its creator can modify it. There are a number of cases where this is important, but the most likely one is a scenario where a piece of pre-prepared text is included in the conference for discussion. In this case, comments may be added as annotations, but the original text most not be modified.

So long as a block has associated with it the meta-data of who its creator is, then locking a block (at least amongst co-operating applications) is simply a case of marking that block as not being editable.

However, given the unreliable nature of the underlying communications protocol, if a block is created as unlocked, and then subsequently, locked there is no guarantee that all sites will receive the ``lock'' message. Given the scalability and resilience requirements, we do not even know for certain exactly who is currently in the session. Thus any site that (temporarily) missed a lock message is still free to modify the locked block until such time as the retransmission scheme succeeds in propagating the lock message. Given a network partitioning, this could be a significant length of time. Whilst this circumstance will probably be rare in occurring, we would like the block locking to be a definite thing - if a user thinks a block is locked, there should be no way for that block to be modified. A similar, though slightly less strong, argument also holds for unlocking blocks.

There are a number of possible ways to ensure that block locking is unambiguous, but many of them infringe our previously stated requirements. The following is in line with our requirements:

1.

Allow new blocks to be created as either ``locked'' or ``unlocked''. Do not allow a block to ever be changed between the two states.

2.

Only allow a block to change state from locked to unlocked or vice-versa by deleting the block and retransmitting its data as a new block.

In the current version of nt, we have only implemented 1. above. We do not believe that block locking is frequently required, and when it is, it is most often required on a block whose data has been loaded from a file. Making the decision about whether or not a block should be locked at load time is quite natural. The default for blocks created on-the-fly is for them to be unlocked.