The VCSK (Virtual Copy Segment) is a much used type of Keykos segment. If S is a VCSK, S produces a factory on command that is a source of new mutable segments each of whose contents are initially identical to those of S which becomes henceforth immutable. This is strategic if the data of the segment is to be compiled by storing into a segment and then delivered to one or many confined worlds that need to further modify the data where such modifications must be confined.

As the keeper produces a factory it delivers a sense key for the top node of the segment, to the factory as a sensory component. The factory can thus produce duplicate mutable segments with no holes. The logic of the keeper code need not be relied upon for discretion. As the new segment is modified new pages and nodes are bought by the new segment keeper instance. The unmodified pages of the segment continue to be shared across protection boundaries. The only nodes that may not be shared are those above modified pages.

Here is an application of VCSK. It would benefit from a strategy to reclaim pages that are no longer accessible by any of the progeny. Such progeny would have holes however. VCSK in the manual

An Analogous version of the Record Collection

The current record collection manages a balanced tree of nodes with pages scattered thruout the tree to hold key values. (In this context “key” refers to the data used to locate the record.) If the record collection code were enhanced a bit it could operate on such a tree with some of the capabilities therein being sensory. When it needed to modify a page to which it lacked write authority, it could first produce a duplicate page to which it had write access. The capability to the new page would go into a possibly new node if write authority to the node immediately above was not available. The sharing between old and new record collections is in the case of the VCSK.

The result would be called a VCRC (Virtual Copy Record Collection).

A significant problem remains. Record collections frequently are to hold start keys. The sensory version of a record collection with unknown start keys must not deliver those keys to the collection holder. It is strategic, however to have such a collection deliver start keys for known discreet objects, such as factories. This would seem to require a kernel mod and it is not clear what the semantics should be. Perhaps some way to extract an intact factory capability from a node via a sense key to the node. The fetcher factory was invented to solve problems such as these. I do not recall the cost of a fetcher factory. I think it is at least a domain and a components node. Could it be an indirect node??