Key Little Visions
December 27 to 29, 1998 - Jack Harich - Go Back
This early document contains quickly written visions of key areas, describing what we really want to do. This eventually crystalized into the Technology Grid.
Vision - User's Point of View
The user gets into "evolve mode" at any point while using a system. Evolver appears, steers user through changes, caters to the user by remembering preferences, habits, skill level, changes made. New app starts with "empty app" with evolver open and suggestions. User is just editing declarative knowledge under evolver's guidance. Evolver is left open all the time if user expects to tune app while using it.
The user is completely able to modify the system to behave they way they want. They can do this very easily. Because of common parts all apps are very consistent.
The evolver itself can be edited, so it is the primal app and the user's best friend. All is built on primal elements: empty app, editor, storage, declartive knowledge, base parts from which other parts are made, etc. Even engine is just a part running itself. Note circular dependencies for primal elements. All elements are replacable parts.
Vision - Part's Point of View
A part lives in a container through which it communicates. It's initialized by declarative knowledge, which is app neutral with goal and policy oriented data. Parts receive and send messages which contain event type and properties. The properties can be primitives, Strings, or "riders" such as datatrons or mobiles. (Any part can be a rider???)
Datatrons are app neutral data structures. A small number of types can handle all part needs. These are expected to be trees, row/column, rows and streams. They can be nested. In all cases the leaf is a primitive or String. The purpose of a datatron is to travel somewhere with data and allow that data to be easily accessed.
A part knows of no other parts. They remain a mystery which it can only query about, but not about the parts, but about the capabilities (services) available. Queries and other data getting is done via "acquire" messages.
Some special parts can communicate beyond their container. Sensors receive input, emitters send output. Some parts need to actually travel beyond their container to other containers. These are "mobile" parts and can send and receive messages to containers, regardless of the part's or container's location.
Vision - Container's Point of View
A container is just a specialized part whose prime responsibility it containing and supporting its member parts. A container is initialized via declarative knowledge, like any other part. When a container receives a message to a member it initializes its member parts, then sends the message to the destination part. Containers can also receive messages to themselves, such as for part re-initilialization or replacement. When a container receives a Close message it closes all its members, and is now in its initial state, ready for garbage collection.
Members can be individually added, removed, replaced, manipulated, diagrammed, etc. A container provides these abilities, which can vary from container to container. This is how systems are evolved. A system is a root container and its decendents.
Containers can accept, house and send mobile parts. Once a mobile part is accepted, messages to and from it are handled like other messages. A mobile part may leave a proxy behind to foward messages after it departs. Mobile proxies can be removed.
If a container gets into trouble, it tries to repair itself. If that fails it can ask for help from the user, the system, or try to repair itself with risk or defaults.
Parts can be replaced anytime by asking a container to replace an old part with a new one. Since all parts communicate only with messages, this involves transfering old part state to the new part and then routing messages to and from the new part. This will require "morph" support from parts for state transfer. Replacability and configurability make product version upgrades easy, even while running, since this is built into the architecture. As society's dependence on software grows, the ability to do upgrades while systems are running becomes critical.
All uses of a part in a system can be replaced by sending an agent through the system's containers. The agent can do a three phase replacement: beginReplace(), commitReplace() or abortReplace(). This handles parts that need to be "paused" during replacement, such as servers, open files, windows, etc.
Note parts normally contain no references to another part, making replacement and reuse possible. Parts doing high speed work need references and may be referenced. This will be resolved by use of state transfer for references and replacement notification or another mechanism for "be referenced".
Vision - Part Shop's Point of View
The part shop is where the user or developer goes looking for parts to use in a system. It can provide empty apps, containers, parts, groups of parts, systems and assistance. It has a huge number of parts in stock, so it has query and search abilities. It knows which parts have worked well, where they are deployed, which are not used anywhere, which are under construction, which work well together, etc. It is constantly improving this knowledge by monitoring or exploring systems and remembering all checkouts and checkins. It also asks users about their satisfaction with parts and the part shop's services, stores this info, and uses these surveys to improve itself with developer assistance as needed. Like all elements, the part shop is built of parts itself.
Parts are added to containers by part shop checkout and removed from containers by checkin. This is done manually by users or dynamically by parts, since systems can dynamically grow or shrink.
Parts are organized in a layered architecture with base parts at the bottom and app specific one at the top, with additional layers such as domain and service in between. Enterprises can organize their parts by describing their preferred organization to the part shop, which is then enforced when parts are assembled from other parts or collaborated with via messages.
Custom parts can be manufactured on the spot or ordered. Users are notified when orders arrive. For example notification could go to a project manager or a developer in a project.
The part shop can send and receive datatrons such as policy changes, state changes, part replacements and alerts to deployed parts, stock parts, deployed systems or particular users.
Some other early notes on the Part Shop:
Empty Part - This part type is "empty". Given state and policies, it responds to input by reasoning, changing its state and emiting output as necessary. Optimization is needed for empty parts to avoid a system built from them being too slow. This is done by Part Mfg. Goal is to eliminate need for any custom coding by producing behavior of any type from DK. This and Generated Parts will herald the end of hand coding.
Part Manufacturing - Add ablity to generate DK from meta DK to produce a part. Add code generation, see below. Add ablity to assemble group of appropriate parts, as a container, for use in a container, or as a skeleton system.
Generated Part - The part shop can generate and compile parts from DK and other parts. This is useful for high speed work, behavior that is hard to express with parameter driven parts, or needs for parts that don't exist. A key threshold to look for here is when generated parts start generating parts.
Part Picker - Works with Evolver to allow picking out needed parts. Start simple with tree, move up to query, search, user favorite parts list, etc.
Part Orders - Add ability to order parts. This will unify project management and address customer's needs better.
Part Inventory - Create several hundred useful parts and some sample systems. All parts must tell how to use themselves.
Vision - Hotel's Point of View
All users enter the Hotel. They must first go to the registration desk and register, declaring their address, skill level, interests, etc. They are then issued an id and a key. They use these when entering the system. They have a private room where they can store anything they want, such as notes, data, parts, system fragments, systems, desk space, custom part policies and such. They can check for messages from others, or send messages to others.
The hotel knows who is on which system, what they've done, what they are likely to need, etc. Policies for registration, monitoring, editing and such are provided per enterprise, group, user, system, etc.