Concern has been expressed that integrity as described can interfere with software maintenance. If the integrity of an factory is real then how do we fix a bug in the factory's .program? There are several conflicting issues here! Some application operators want to delegate responsibility to the "facilities maintenance personel" to always provide the best objects they can. Others look with a jaundiced eye toward any changes.

As a concrete example of the latter imagine the most recent bug in the record collection. The record collection mal-functioned only when records plus key were less than 11 bytes. (This fact followed from study of the failing code.) The fix was over 100 lines of new code. If some real time application was using the record collection with a vital long lived file and it was known that there were never records that short it would be foolish to try a brain transplant for that file.

By contrast it might be discovered that a bug in the record collection causes failure when a certain size is reached. The file in question is destined to reach that size in a few months. The bug can be fixed with a change of one bit in a BC instruction. In that case it is foolish not to fix the bug in the running program.

In these cases it is necessary for the supplier of the record collection service to consult with the application operator inorder to determine the correct action. In the latter case I would propose a program designed to wield the domain creator key from the record collection factory. The program would accept a key to a record collection and do the transplant. A key to the program would be made avaible to application operators along with an argument about the safety of the transplant.

Some applications will want to use a factory requestor's key that always yields the most modern object available. Others will want a constant factory. Yet others will want to defer the decision by indirecting the requestor's key so that the decision can be made after the exact nature of the next bug is known. We support all of these. The JOIN-USER function has the option of providing either or both kinds of factory. We should not hobble this flexibility.

There are many other situations more delicate than those described here. I see no end to them. I am skeptical about general solutions. Capability systems such as ours get in the way of the system administrator's natural instinct to always provide the best version of the software that he knows how. Some application operators will be prefer this situation.