The art of progress is to preserve order amid change and to preserve change amid order.

Alfred North Whitehead

Upgrades are a challenge with persistent state. An upgrade generally involves replacing old behavior with new behavior, perhaps preserving state. Sometimes the new object is based on different foundations. Capability systems do not provide a uniform way to do this. It is not always possible to upgrade a system component at an arbitrary time.

Here are some reasons for upgrades:

  1. Your arrangement with the software owner has expired or is about to expire.
  2. The new software is better: better features, smaller, faster, fewer bugs.
  3. The new software is already in use and already occupies RAM; i.e. consolidation.
  4. The new software has a more familiar interface, as the user uses it for other purposes.
  5. The foundation for the old software is going away.
One fairly general plan that is more feasible than in conventional systems is to build a new version and run in parallel for a while. This can be difficult if some of the objects of the old software have obscure state. Upgrade software may come with upgrade logic to automatically produce a new system with the old attributes.

A program designed to learn your idiosyncrasies (subtly adapt to you) is unlikely to yield its secrets, even if its designer intended it to do so. A speech recognition program that learns to understand you is likely to keep its learning in a proprietary form that other programs could not understand even if the data were not secret and proprietary to the owner of the old program. A new program by the same author has some hope of starting where the old program leaves off. A money object will be unlikely to abandon its fiduciary responsibility to the central bank.

While there are no general solutions there are a few schemes that serve particular situations.

It should be rather easy for new behavior to begin with the state of old objects that:

In such cases the new object can accept a capability to the old object and retrieve its state. This is not usually destructive of the old object. In common cases program logic in the new object will promptly query the old version of all its state and dispense with the old object before beginning to interact with the user.

A slightly more complex protocol may be used when the state or its format is proprietary. A new object that is trusted by the old object may acquire a capability to the old object that is stronger than that held by the user. Via this new capability, the object keeps no secrets. This new capability can be had thru rights amplification from the creator of the old object if prior arrangements have been made with some agency with authority over those proprietary issues. This scheme may impact the design of the apartment.

Another problem arises when the object to be replaced is unknown to the user but is used by other programs. Here the user relies on the object to be upgraded, but only indirectly. If the user relies on B which relies on C which needs an upgrade, and the user still relies on B’s author to support B, then the transaction appears to the user as an upgrade to B. There are several scenarios here depending on who knows what when and who has a reputation on the line. More on that later perhaps.

Upgrades vs. Security

Techniques to upgrade the behavior of existing objects are very likely to conflict with various real security issues. The object’s owner may have come to trust the old code (behavior). There may be bugs in the new code. The producer of the new code may have motives beyond those of the current code. The owner may have more at stake than when the existing object was new. Should sibling objects of different behavior trust each other? A can of worms.

Summary

Upgrading software in running systems is hazardous. Capability architectures get in the way of naïve methods of upgrading. This is often good. There are upgrade schemes within the capability framework that can be rehearsed so as to limit the probability of disaster during the transition.