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.