There is a cluster of concepts about objects that can be extracted from a computing platform.
Some of the following issues are orthogonal; others are not.
It seems to me that any meaning for extraction must be an integral part of the meaning and purpose of the object.
Perhaps we can find a general contract for behavior of extractable objects.
Most of the objects for which Keykos was invented will be unable to conform to such an object, but that’s OK.
Perhaps most objects of conventional design and purpose can conform.
- Is extraction compatible with the purpose of the object?
A money object cannot be extracted just as currency may not be duplicated.
- Is behavior to be included in the extraction?
A Microsoft Word document in e-mail does not include behavior, only a conventional hint of behavior.
- Is state to be included?
An .exe file in Windows is behavior plus possible state.
- Is extraction compatible with the commercial purposes of the provider of the object?
Extraction may be limited to ensure property rights.
- Is extractability manifest as discretion is manifest? Is that possible?
- Is there a suitable external concept of type that can support assurance that an object extracted without its behavior can be revivified on another platform?
- “When we tug at a single thing in nature, we find it attached to the rest of the world.” —John Muir
- Some things just make no sense outside their community.
- Moving a city is nonsensical.
Moving a company is often fatal.
- You tug at some things in a conventional OS and you just get a bloody stump.
Perhaps it is better that you cant extract some things in Keykos.
- What might it mean to extract a read-only page key to a page into which an asynchronous service is depositing weather forecasts?
Manifest Behavior is a related difficult problem.
The plan here is to follow the Factory pattern to define a category of Keykos objects that are extractable;
to make things extractable by construction.
There are a few philosophical issues to explore first however.
Presumably an extractable object responds to some order to disgorge itself by returning data that can be used somehow somewhere later to reconstitute another object with the same behavior and same state.
This characterization already reveals several surmountable problems that must color our solution.
It seems clear that extraction of an object must be done on terms of the object itself.
Few of the security goals of Keykos remain if there is some sort of compulsory revelation of state.
An object may be willing to divulge its state but not its behavior.
The behavior may indeed be proprietary or just plain secret.
It may be implemented in proprietary code, which is slightly different.
For commercial reasons it may require that the behavior be acquired for reconstitution separately, perhaps by invoking a factory on another machine and presenting it with the coded state.
The metaphor that comes to mind is of the wary traveler enticed to some novel form of transportation, to an unknown place.
Suspicion like that engendered by cryogenic suspension or teleport schemes seems likely.
The things that can go wrong are highly analogous.
The psychological underpinnings are not, except for an urge to guard integrity of the persona.
An key may be a facet to a complex of objects with shared state.
Conceptually the state of the object includes keys to other shared objects.
The semantics are highly ambiguous.
The holder of a domain creator DC for a class of objects might choose to submit that creator to a registry of DCs for which simple extraction is thereby afforded.
The registry submission might also include a crypto key to be used to encrypt serializations of the yield of the DC.
This would serialize a simple class of objects.
The common serializer would open the object with the DC and without affecting it
extract its data and capabilities, assuming that the capabilities therein were likewise extractable.
Designers of mechanical things must often make tradeoffs between replaceability of parts and durability of the system.
The CPU chips of some computers are sometimes welded to the MB but in other systems come in sockets.
IBM systems had identifiable FRU’s (Field Replaceable Units).
I suspect that the tradeoffs were similar.
Plug and Play is a similar game.
An extractable thing is presumably cloneable for that raises fewer issues for there is no issue of revealing proprietary methods of coding the state.