Gnosis allows many kinds of sharing unavailable in more traditional architectures. Unlimited use of these features makes copying and moving things difficult.

“When one tugs at a single thing in nature, he finds it attached to the rest of the world”.

John Muir

Other operating systems have primitive operations to copy things {usually files}.

There are a variety of problems that may have a common solution that seem similar to the copy function. These problems are:

We would like to move an object, such as an SK1 segment, to another Gnosis system.

We would like to preserve an object for incorporation into the world of a new big bang.

We would like to move an object from one space bank to another.

We may want to place the deletion responsibility for the object on someone new.

We may want to place the cost of preserving an object on another budget.

We would like to make a copy of an object to preserve the information that it embodies anticipating that the object will continue to change and that we will want to consult the old information.

New command systems from factories.

We said above that the yields of factories might be copyable. One of the things that we pine to copy is the whole world of a user so that we can move him to another system. Suppose, therefore, that we make the command system invocation spring from a factory. You may recall that this also solves a problem of mandatory security policies.

While we still do not know how to make a copy, we can begin to see what it means to make a copy.

What holes may be in this command factory.

The SIK3, SOK3, and CCK3 of a zapper module {(p2,zm)} are in the factory. The ZMK to the same module is on deposit with the receptionist.

However indiscreet a set of factories that are to be allowed will be found in the command environment generated by the command system factory.

One might naïvely hope for a “copy object” function that would take any key and return a key to a new object like the one designated by the original key.
Consider, though, the SIK key, or even the CCK key. There is no current idea of an object that they represent.

Consider a key to a record collection {(rc)}. Such a collection is of records which are composed of text and a key. We can clearly copy a record by copying the keys and texts to form a new record collection like the old. If the collection is a directory the user might think of some of the keys (that are to other collections) as sub-directories of the original, in which he would expect them to be copied. Other members of the directory, which designate record collections are thought of otherwise and should not be copied. How is the copier to know?

If there were a concept of an “owning reference” and a “subsidiary reference” we could copy the objects designated by the owning references and not the others. I record this idea but I will not pursue it here.

Putting copy logic in a space bank
The presumably official bank found in the factory is, indeed, checkable only by the presumably valid space bank transformer. If these are in cahoots then the fake bank is in a position to keep track of the nodes and pages that are the material of the object. It can, when it is time to copy, discover what keys within the object, designate other parts in the same object. It can thereby model the object in a running functioning new model.

Space banks certainly have extraordinary power but putting logic there is bad because banks are so fundamental. It is nearly as bad as modifying the kernel.

On the other hand, it might be the case that users of such general copying facilities are ipso-facto subject to the bugs of such logic and thus it makes no difference to them whether the buggy code is integrated with the space bank or not: they are just as dead if it breaks.

Non users of the copy facility are not endangered if they do not use space banks with the copy function.

Suppose that we make a variant of the guarded space bank. It provides the functions of the guarded space bank and in addition obeys the “copy world” command. Suppose that we make this bank the only bank available to the .program of a hole-free factory.

When the bank is called upon to “copy the world”:

Some nodes have processes in them. This needs to be determined. Perhaps the only meter should be turned off. A program standing in the position of the keeper of that meter would then be in a position to collect exits to those nodes with processes. But how long must he wait??

The bank contemplates each of the node keys that is has kept. It creates a new node for each such key and places keys in the new nodes to correspond to the keys that it finds in the old nodes. This correspondence requires being able to determine if a node designating key designates a node for which the bank holds a key.

The facilities of (p2,node-cmp) provide most of what is needed here. It may not be sufficiently easy, or even possible, to tell what kind of key to the known key is held.

Another issue is the efficiency of finding out which nodes are designated by which keys. A key indexed directory {(p2,kid)} can solve this problem efficiently.

Another problem is to copy the pages. This is easy. Page keys found in the nodes may likewise be identified with the pages that they designate.

There remains the issue of returning to the requestor of the world-copy, keys suitable for the situation.

What does “copy” mean?
We need to get more precise about what it means to copy an object. What does it mean to copy a random number generator?

Before I attempt a definition lets make some rules that we would like to be true and that should follow from any definition.

If I make a copy C of a record collection R then the two collections should have the same records (in the same order if they are entry sequenced).

We have shown how to represent cash with Gnosis objects. If such objects were copyable by the holder this scheme would fail. We conclude that the owner should not always be allowed to copy his objects.

A perceived dilemma in both language design and Gnosis design is to know when to stop copying. I say “perceived” because I think that the solution, when found, will answer this question naturally so as to make the dilemma unprofound and uninteresting.

Copy in another messy case

Suppose that we call a factory filter that produces copyable, discreet filters that have one consuming interface and one producing interface. Such a requestor call takes two co-gates and returns nothing.

How does one request a copy of such an object?

We must first ask what it means to copy such an object?

This in turn leads to the question of motivation of the copy. There are two programs with a view of the filter, the data supplier and the data consumer.

Assume, for concreteness, that the filter watches raw stock data and provides reduced and processed data for the consumer.

Assume that the consumer is to move to another machine and that we wish to copy his world there. He has built the filter and thus it belongs to his world. In this case he will be copying his world which presumably includes the filter. The question remains of the supplier.

Before the move is consummated one of several things must be done about this connection:
It might be abandoned, in which case the filter will most likely receive an end of data signal after the move.

A similar service might exist on the other machine: ...

Whether such service can be continued transparently to the filter and supplier seems doubtful.

We might make provisions for the raw data to be transmitted to the other machine.

We might wish to make provisions for the filter to stay behind and pass its results to the new machine.

As we contemplate these situations it seems clear that such actions require some sort of anticipation during construction.
One sort of anticipation is easy but expensive. Another filter between the supplier and the filter can be installed at construction time. It can do any of these tricks. In fact the particular trick can be specified at the time of the move.

I conclude that if two systems are communicating according to the co-routine protocol, there is no way of separating them transparently to both.

At the time of the copy the filter may or may not hold an exit to the supplier.

If the filter holds the supplier exit:

If the supplier were being copied, due to requirements beyond to scope of the logic of the supplier, the filter might be required to be copied.

I think that the modified factory returns a copy key to the requestor.

I think these problems can be overcome. I outline here some half-baked ideas.
The logic that limits pointers in an object to things outside the object might somehow control the ambiguous pointers that plague the copy idea.

Pointers found inside objects, created by a factory, got there by one of two ways:

They are an official hole,

They were passed in by the requestor after the creation.

Holes can be handled on the same ad-hoc basis that their security considerations are now handled.
Since holes tend to be to some sort of standard object, the meaning of the key in the copy can be defined on an ad-hoc basis.
If the hole were to an error logger, the key might be replaced by another to the same logger with a new data-byte, thereby distinguishing errors reported by the original from those reported by the copy. The logger administrator is thus in a position to know that the copy is occurring. The factory presumably holds a requestor's key to the logger administrator.

Some objects might be endowed at request time with weakened entry keys that would support neither the import nor export of keys.
With this weakening we come to the kind of object supported in some other object base operating systems. This weakening is a policy that the object's code is clearly in a position to enforce. Providing weakened entry keys provides for the possibility of objects that are manifestly copyable without the cooperation of the code inside.

Let me hint at the solution I am leading up to: Suppose that the yield of a factory were formally designated as an object and a capability generated at creation time that could be used subsequently to copy the object. Let me list the problems first:
I am not sure how to implement this,

I still don't know what it means: What about the recursive directories,

Where do you conveniently keep the copy capabilities so you have them when you need them?

It seems desirable and possible that some generalized copying facility could be provided with some restrictions necessarily imposed on the design of the objects to be copied.

Algebraic Specifications

Those objects whose nature can be specified by “algebraic specifications” seem all to be of the copyable sort. By this I mean that I know what it means to copy them.

Lets review the form of an algebraic specifications.

We have the concept of an abstract value of the given type of object. If the type were a “name sequenced record collection” the value would be a set of particular record values.

We are given operators which are just functions which yield either a datum or a new abstract value. These operations typically take just one abstract value as one of their arguments.

Objects as complex as relational database systems have been given algebraic specifications. These are, in some sense however, simpler than CCK keys.

Common programming languages have primitives to copy the values that the programmer works with. Some programming languages, especially recent ones, support the concept of values being composed of simpler values. Some of these languages support the copying of these composite values directly. In the others the composite values can be copied only by copying the component parts.

The advent of languages supporting data abstraction has brought a new dilemma:

Since the parts of a value are hidden from the owner of the value, he cannot copy the value directly as he could have had the components been available.

Should the user be allowed to copy such composite values?

The designers of the Euclid language decided to let the designer of a new type of value choose if such values should be copyable. {Such values are also comparable for equality at the designer's option.}

Other languages have provided special hooks for the designer to participate in the duplication of objects of his type.

We want to find some rules which object inventors can follow so that their objects can be copied with little effort on the part of the designer.

Ideally we would find rules compliance with which would be manifest. This would mean that evidence that the copies were different from the original could be laid at the feet of the copy mechanism.

Some Relevant Digressions

I think that each hole of a factory will require special consideration in the definition and implementation of copying the yields of the factory.
Perhaps some hole categories can be invented, such as repair services, that can be handled in a uniform manner.

Exercise for reader? (& me too): Can (and should) a repair service make a copy?

What does it mean to copy something that is a functioning part of a larger system?

This can be answered only from the perspective of the larger system.

In the Gnosis world, however, a component may be a portion of two larger, otherwise disjoint systems.

A problem that must be solved is what to do when the requestor of an presumably copyable object entangles that object by inserting a key to the outside world. This is the problem that led me earlier to propose some circumstances whereby you couldn't pass keys.
One point of view is that copyable objects should communicate with the outside world via gate jumps that pass only data. This is too crude a rule -- consider the exits that calls implicitly pass?

How about gates that will not pass gates. This is a kernel change. That is bad but let us proceed for a bit.

Copyable objects would be unable to become entangled with the outside world because communications with the object would not pass keys.

The .program of the current style factory finds an exit key to the requestor. Suppose that this exit key were of this “don't pass entries” kind.

VERY LOOSE END!

This whole thing is tied up somehow with rescindable access to objects but I don't know how.
If you can rescind, you can also sever and replace the connection with logic that implements whatever policy is desired to handle the cloning dilemmas.

Cloning dilemmas are familiar from science fiction.
If you duplicate someone, which clone gets the bank account?

While there are no “natural” solutions to these dilemmas, it is comforting to note that there are a variety of ad-hoc solutions to these dilemmas.

An ad-hoc solution to the bank account problem is to divide the account into two accounts, each of half the size.

The drift of the above is that the copier must know about each of the foreign connections and take special account of each. I think that the request to copy must somehow specifically consider each of these outside connections.

Creating objects vs using objects. (Dead End, I think)
Gnosis domain code seems to be divided into two activities: creating objects and using them. (Of course a program uses other objects while creating an object.)

Suppose that we presumed the following rigid restriction of modes of programming in Gnosis. These restrictions might be enforced somehow.

All creation is done with factories.

Gate jumps not “involved with creation” can't pass capabilities.

Some provision must be made for record collections and super nodes, for one passes keys to and from them after creation.

The germ of the idea is that the yields of factories would be somehow copyable.

The restriction against passing capabilities is to avoid the entangling alliances that lead to uncopyable things.

Hint: I don't think we have to change the kernel.(??)

I think that there might be an enhanced kind of factory whose yields would be copyable. These factories would require special attention when holy requestor's keys were entered into the nascent factory.
The factory could substitute an unofficial space bank that used the provided official one. This bank would keep keys to the material that it provided. It would then be in a position to copy the structures built from this material. The factory would also have to replace the space bank transformer with a substitute that would make the unofficial bank appear official.

This implies that we know what to do in the case of hole-free factories. This is yet brash.

I can see the outlines of a command system factory that produces “work-spaces” for a user that can be checkpointed, copied, moved to other systems. This needs to be generalized so that the user can, himself, checkpoint, copy and move his own objects.

The generalization breaks down because the user can entangle his object so as to be unable to find its boundaries.

A work space might be provided where all outside connections would be registered so that they might be reviewed by the copier (or security officer).

Where does one place the copy logic that we have implied?

Even if we knew where the edges of the object were how do we reach them?

The ideas of (gnosisdoc,x-ray,) might do the job but I hope that they are unnecessary. The lesser facilities of (rel-unspec) would already do the job I think, but still by wielding overly powerful tools.

Fuzzy view
I now think that the solution is an enhancement of the guarded space bank. A variant of the guarded bank is willing to make copies.

One may determine if a given bank is willing to make copies. Some .programs may be unwilling to use such a bank (Accounts?).

There would be a call (on the guard key?) that would make a copy of all of the guarded material. In addition it would return analogs to keys provided upon the copy call.

This call would take a new space bank (which might or might not be guarded etc.) which would provide the material for the copy.

There would be a transformation on a willing bank to produce an unwilling bank. This is necessary if I want my command system to be moved to another Gnosis system. I would loose my bank account but that seems necessary.

More said:
There is a bank transformation (call to SBT?) that produces a bank and a guard key G much like the guarded space bank {(guard)}.

{“copy object”} G("copy";KO,B==>c;KN)

We use “safe” as suggested at (guard) to refer to those pages and nodes remembered by the guarded bank.

G obeys a new order code called “copy”. B is a space bank. KO is a key {presumably designating a node from the bank}.

For each node safe node N a new node is created from B. This new node is said to correspond to N.

For each safe page create a new page from B. The new page is said to correspond to the safe page.

For each key K in a slot of a safe node the corresponding slot of the new node is filled with KX where:

If K designates a safe node or page then let KX be like K except for designating the corresponding node or page. Otherwise KX is K.
This requires the bank to hold a domain tool to make gate keys to nodes.

The key KO is likewise transformed into the key KN.

Programming notes:
More mapped keys:
Question: If you hold several keys to the designated object how do you get the corresponding keys to those?

Answer: You get a node from the bank, put those keys in it, pass the key to that node as KO, Upon return KN will designate a new node from the new bank with the mapped keys.

Warts and deficiencies:
Export - Import
This function should also allow for “exporting” structures. For one example how do we get the copy to appear at the other end of a phone line?

In the extreme paranoia mode we would have to have two kindred banks communicating over some secure circuit.

We should modularize the solution so that ciphering code isn't the space bank.

DCC and brands
Should the dcc found within the factory have been called, should we make the brand of the corresponding DC the same or different?

What should we do with processes?