14.3.5. Removing a context instance
A context is embedded in the network of contexts and roles through the connections of its roles. In order to remove a context, we can simply
-
remove the incoming links (fills and filledBy) of all of its roles
-
and then throw away the context and all its roles.
In other words: the internal structure of the context does not need to be torn down to remove the context (but see below for role state evaluation).
A user is endowed with a set of perspectives that are qualified by role- and property-verbs, including verbs that allow her to remove information:
-
Remove
-
RemoveWithContext
RemoveWithContext, RemoveWithContextLocally, DeleteWithContext, DeleteWithContextLocally are not yet implemented in InPlace v.0.12.0. We will introduce them to indicate whether the perspective allows removing (or deleting) the bound context, too.
-
RemoveWithContextLocally
-
Delete
-
DeleteWithContext
-
DeleteWithContextLocally
-
RemoveFiller
-
RemovePropertyValue
In order to initiate removing a context, a user must have a perspective on a contextrole filled with that context, with the verb RemoveWithContext, RemoveWithContextLocally, DeleteWithContext or DeleteWithContextLocally. These are the only verbs that allow removing a context.
Notice, that, in effect, RemoveWithContext implies Remove, RemoveFiller and RemovePropertyValue. DeleteWithContext implies Delete, RemoveFiller and RemovePropertyValue. However: this does not mean that a user with a RemoveWithContext perspective therefore has the right to remove individual roles, for example.
The verbs that end in Locally permit the user to remove or delete their own copy of a context, but peers are not required to do the same. However, they must annotate the user roles with the removing peer such that they are no longer involved in the synchronisation process.
14.3.5.1. State evaluation
Before a context is removed, it exits all its active states. This happens in exactly the same way as for roles: deepest nested active states are exited first and all actions on exit are executed in the same stage.
Consequently, all statements are executed while the context is still fully intact. For each statement, the modeller can ‘reach out’ of the context and change things there.
Can he change the context that is about to be removed? He could, actually; and this may affect the states that are subsequently exited. Another reason to modify a resource that is about to disappear would be to enable conditions for statements that follow. The modeller is strongly advised against this (we may add, in the future, a compiler check that warns against this), because it makes removing a context less transparent. The acting user removes the context based on what she can perceive of it; if it is modified on the fly, she actually removes it in a different state from what she thought.
None of the modifications to the context or its roles itself, make a material difference for peers: they throw away the entire context. Of course, modifications outside of the context that is removed, will be communicated to the peers.
14.3.5.2. Embedded role state evaluation
What about the roles embedded in the context? They are removed, too, so they should exit their active states as well. The question is: do we exit role states before, or after context states? We choose to exit them before exiting the context states.
14.3.5.3. Synchronization
Removing a context is a very powerful operation. All peers are required to remove their local version of the context, too, completely. Even if it holds more information than it did for the acting user, they should still remove it entirely. Synchronization is therefore simple, because it consists of a single delta that instructs the receiver to completely remove the context.
Consequently, we do not need to collect deltas when we actually remove the context, detaching it from its surroundings. All these deltas are superseded by the powerful instruction to remove the context, making them redundant.
We may ask ourselves: can there be a peer with a role that fills a role of the removed context, without having a representation of that context? The answer is no, because each reference must be locally resolvable. That is, the ‘fills’ link of that peer must point to a role that is present in his installation – and hence the context is present, too. The same holds for a link in the other direction.
Which peers that should be informed about removing the context? This is the union, over all roles, of the peers that should be informed when the incoming pointers to the role are removed.
On collecting those users, we should not already remove the pointers. Otherwise, for each consecutive role instance, the computation is carried out on a diminished context representation. A simple example shows why that is a problem.
Consider a context with two user roles, filled by different peers of the acting user (who removes the context). Clearly both peers have to be informed that they no longer fill a role in the context after its removal. However, were we to remove the roles one by one, it is obvious that
-
the removal of the first peer can be communicated to the second peer (who is still in the context)
-
but the removal of the second peer would never be known to the first peer (who is, after all, no longer present in the context by this time).
So, in effect, we first run a kind of simulation of removal of the context:
-
first we collect peers that should be informed when incoming pointers to the contexts’ roles would be removed;
-
then we exit, for each role instance, its active role states;
-
finally we exit all active context states.
Only then
-
do we send the context removal delta to the collected peers;
-
and we finally actually severe incoming pointers and remove the resources.
14.3.5.4. Synchronization may need passing on
The user that removes a context, may not have a perspective on all users in that context. As a consequence, he cannot inform all those concerned about its demise. This means that we require the synchronization mechanism of passing on. This is that some users receive the delta not from its originator, but via other users in the context.