=-- This distribution rendered properly... -=
=---- http://www.prairienet.org/~yamada ----=
=---- mailto:yamada@acm.org (haiku) --------=
=-- when these lines have equal length. ----=
=----beginDocument
Draft only, v0.3.1.
05061999-12241999.
1291 lines, 43,746 bytes.
7-bit ASCII, 67 characters wide.
Comments: yamada@acm.org
Nothing is everything.
=-=-=-=-=-=-= =-=-=
I n c a r n a R F C
=-=-=-=-=-=-= =-=-=
========
Contents
========
(0) Contents
(1) Binding language
(2) Motivation
(3) Summary of system behavior
(4) To do
(5) Puzzles, constraints, solution factors, and comments
(6) System internals
(A) Notation reference
(i) Class and interface notation
(ii) Variable notation
(iii) Method signature notation
(iv) Data signature notation
(v) Process control notation
(B) Implementation elements
(i) System architecture
(a) Motivation
(b) Vectors of change
(c) Client-server
(d) Model-view
(e) Code layers
(ii) Site characteristics
(iii) Site objects
(iv) Relational tables
(v) Compound data structures
(C) Interaction elements
(i) Element hierarchy
(ii) Element properties
(a) Animator/Time machine
(b) Editing Console
(c) Injection Console
(d) Serializer
(e) Incarnator
(iii) Element syntax signatures
(D) System classes and interfaces
(E) System behavior and element interaction
(i) Incarnator behavior and interaction
(ii) Injection Console behavior and interaction
(iii) Nodebank Console behavior and interaction
(a) Multiple linkable editing consoles
(iv) Personification Engine behavior and interaction
(v) Scripting system behavior and interaction
(a) Direct cycle mode
(vi) Snapshot Serializer behavior and interaction
(vii) SourceVision behavior and interaction
(viii)Synchronized Serializer behavior and interaction
(F) Scripting
(i) Scripting terminology
(ii) Scripting purpose
(iii) Script characteristics
(7) Product development
(A) Information sharing
(B) Orders of implementation
(8) Signature index
(A) Variables
(B) Methods
(C) Data structures
(9) Glossary
================
Binding language
================
This document and the ideas herein expressed are the copyrighted
intellectual property of William Paul Fiefer, all rights reserved,
1999.
This document may be freely copied, distributed, and used only for
educational purposes provided this binding language credit and
agreement remain intact and attached to all renditions.
By accepting or reading this document you consent to make no
commercial, military, or criminal justice use of the ideas herein
expressed. Any artifacts or products incorporating the ideas herein
expressed are directly and without exception subject to this
agreement and can be freely copied, distributed, and used, in
intermediate and final forms, without charge or penalty unless
otherwise stated by subsequent amendment of this agreement.
==========
Motivation
==========
The World Wide Web lets us edit and relink only the small sections
of it directly under our control. We can't change the content and
hyperlink configuration at arbitrary parts of the Web, and we can't
clearly watch the content and hyperlinking of the Web change over
time. This makes it less useful and powerful as an information
tool.
This static information quality effects us even if we don't
directly use the Web because browsing and hyperlinking have moved
to intranets and extranets, which don't have to be on the Internet
but still restrict our use of information. We can't articulately
control what information we see and use or want to see and use. We
can't comprehensively look at how that information evolves in time
and space. This makes it harder to get knowledge, share knowledge,
collectively build knowledge, and understand knowledge.
The best information is free of such restraints. The best
information lets us see its history, decide its shape, and choose
what to make of it and what to take of it. So we propose a Web any
part of which can be browsed, edited, and relinked by any of us. We
propose a Web that permits this freedom, but doesn't destroy the
content and hyperlink structures of others because we want to
respect the shared information space even as we transform it. And
because we want to explore the fundamental nature of computer
networked knowledge, we propose a Web than can regenerate any of
its previous states as well as every transformation it followed as
it changed from state to state.
The social space created by such a Web lets us link and share
information without losing links and information we already
possess, and it lets us explore the transformation of this shared
information. If we build Webs like this, they will reflect our
evolving ways of seeing the world and provide us with greater
information flexibility and power.
==========================
Summary of system behavior
==========================
The system's purpose is to store, recover, and structure
information to allow its users to see and manipulate this
information in novel ways. The system is constrained in that it
must not impose context on information and it must not destroy any
information context that its users create. In other words, the
system must allow its users to recreate any of its past states
while imposing no state of its own.
The system structures files and programs into a dynamic,
nondeterministic site using the visual metaphor of the World Wide
Web. It transfers information to remote locations using the
Internet or any network. The backbone of the system is a relational
database: all documents served at the site reside in this database
and are dynamically loaded as pages on request.
The site does not exist until a visitor interrogates it; only then
do its pages and hyperlink relationships coalesce, and then, unless
otherwise requested, the site assumes a page-hyperlink
configuration specific to that one visitor.
For any visitor, the site is malleable (customizable), searchable,
sortable, and updatable, just as if the site belonged to that
visitor alone. Any visitor can freely edit any part of the site and
relink any part to any linkable object. Any visitor can add as many
documents as they wish to the site or remove as many documents as
they wish. In adding documents to the site, the visitor can choose
to add them to the database without hyperlinking them into the
site.
At the same moment these custom views of the site are visible to
any given visitor, different views of the site are available to
other visitors. Visitors can view each other's sites
without restriction or they can specify visibility restrictions on
documents to limit outside access. This raises opportunities for a
community of users to grow around a distributed pool of shared
information, and to edit and add context to that pool without
intruding on the existing information constructs of other users.
We mentioned that the views existing at the site prior in time to
any edit are fully recoverable and equally visible. This is full
information rollback. No existing documents or hyperlink patterns
are ever destroyed; once created they are retained unaltered in the
database. As a result, the site grows organically and any arbitrary
point of its growth over time is recoverable immediately by any
visitor as an archive, without using any explicit recovery process,
backup medium, or backup procedure.
We also mentioned that, by default, the site imposes no apparent
context, not even the context of time, on its content until
explicitly requested by a visitor. This is a property of the
database data structures as well.
The site is, optionally, permuted by a script, optionally written
and input by the visitor, and transferable to other users wishing
to share these animated views. By zooming a view out, the entire
site is visible as a large, linked tree, and the movement of this
tree during permutation is called `animation.' Web sites are easily
represented as tree structures and the proposed means of animating
such a structure is through the use of affine transformation
methods.
Animated sites are viewable in one of two ways: quasi-literally, as
trees, using a tool called `SourceVision,' or figuratively, as
personas, with each node taking the role of a character in an
animation, using a tool called the `Personification Engine.' The
SourceVision output takes the traditional quantitative appearance
of information while the Personification Engine presents
information in a gamelike manner. Either output is instrumentable
and printable for analysis and display.
Visitors can archive entire sites or subsites through
`serialization.' Serialization is of two flavors: snapshot and
synchronized. A snapshot archive represents a site stored even if
information transactions are underway. Thus there can be
transactions underway during the snapshot that are not recorded
because they have not completed and do not reside in the site
database. A synchronized archive represents a site at stasis with
all of its information transaction complete. For this
serialization, the site is recorded during a static,
transaction-free moment.
Visitors view the site using browser-like consoles, and edit site
content via a set of editing consoles. Scripts are loaded and
executed at a site using the `Injection Console.' Optionally, the
visitor can edit site content and submit scripts for execution
using email. A utility called the `Incarnator' automatically
converts legacy Web sites into the structured data formats used by
the animation software. The `Serializer' archives the site.
A layer of software directly over the database provides many of
these behaviors and utility. A second cluster of software residing
on a visitor's computer provides the remainder. But the bulk of the
site is its content, in the database, provided by all of its
visitors and preserved indefinitely as a record of the social
transformation of information.
Java, Tcl, and SQL are preferred languages; C++ and Perl are
alternates. Code formats include servlets, applets, beans,
applications, and scripts. SQL is the workhorse, driving the site
as it is dynamically generated.
This document represents the elements of one approach to solving
the problems of this system's design; it does not necessarily
contain final programming constructs.
The working project title is `Incarna.'
=====
To do
=====
Software is ideology expressed as a process. Its development,
operation, and internal structures recapitulate the social
relationships of its builders. There is lots to be done before we
release Incarna from captivity. Become famous, change the world.
You can help. Here are a few ways.
(1) Our system needs additional fundamental design. Specifically:
-- A core prototype model to base development on.
-- A rich set of system classes.
-- A stronger data model.
-- Typed, dimensioned structured database elements (abstract
data types).
-- Method APIs over this data API to manipulate it in a
fine-grained manner that allows the methods themselves to be
combined into more complex compound methods.
-- A class architecture over the data and method APIs to
organize them in a comprehensible and utilitarian manner.
-- A software layer expressed in the class, API, and compound
method terms to make the site useful to general and technical
users.
-- A full-featured scripting language to control execution of
the system.
(2) Our system needs to be extended so it has use in other efforts,
inside of, enveloping, or replacing new or existing programming
applications for specific clients and domains. For example:
-- An XML schema that provides Incarna with a more flexible,
powerful display model. XML is the preferred markup language.
-- An XML schema design for use as a common transmission format
for the structured data elements.
-- Using the DOM (document object model) to give Incarna greater
control over document elements.
-- A collaborative work environment similar to groupware or
enterprise resource planning (ERP) packages.
-- Collective storage and use of ideas in environments in a
manner imposing as little structure as possible on the context
in which those ideas are stored and, optionally, presented.
-- Public service journalism (activism, hacktivism) such as putting
the HAZMAT data on the Web, for searching and continuous updating.
-- Forums for unimpeded public expression and community
creation.
(3) Our system needs primary lifelines:
-- A Website.
-- Content and content editing.
-- Technical reviewing and recommendations.
-- Detailed expansion of this document into a clear programming
specification.
====================================================
Puzzles, constraints, solution factors, and comments
====================================================
05061999
=-------
Puzzle:
-- Restore a specific moment in site time and animate the site
either forward or backward from that point.
Constraints:
-- When a NODENAME is changed, a new NODENAME is added to the
database; the preexisting node can not be removed or altered.
Solution factors:
-- The granularity of the site timekeeping mechanism.
-- The timestamping and new information on new nodes.
-- The means of expressing nodes as subclasses of existing
nodes and storing this information as records.
-- The distinction between call or copy `by value' and call or
copy `by reference.'
-- Change-dependent and change-independent node timestamps.
Comment:
-- This mechanism is the key to animating the site. Applying
affine transformations to the subsequent data structure is
trivial.
================
System internals
================
Notation reference
=-----------------
Notations are conventions for clearly displaying the ideas
expressed in code. They do not necessarily represent these ideas
in the best way, but they represent them in a way that allows
us to communicate with less ambiguity.
Class structure, variables, API methods and data signatures are
best communicated among developers using such a compact,
unambiguous notation. The Java programming language syntax
underlies our preferred notation.
The following notation examples are ordered alphabetically,
defined, and followed by code fragment samples.
==> Class and interface notation.
Representing classes and interfaces: The representation follows
the syntax established in Java.
Broadly, interfaces tell you the terms used to think about a
problem, abstract classes tell you those terms and perhaps some of
the ideas behind the terms, and classes tell you both the terms and
the ideas implementing them. If you take issue with the expression
of a particular idea, subclass its containing class and override
your point of dispute.
For example:
// a class
class Node{
Timestamp id;
String humanname;
String content;
Itemslots itemslots;
public Node();
public isRoot();
public isLeaf();
}
// an interface
public interface Node{
Timestamp id;
String humanname;
String content;
Itemslots itemslots;
public Node();
public isRoot();
public isLeaf();
}
==> Variable notation.
Variables are represented by type or class, and name. Class
variables have figurative names while local variables generally
do not.
For example:
// by type with a class variable name
int pixelWidth;
// by type with a local variable name
int x;
// by class with a class variable name
String name;
// by class with a local variable name
String s;
==> Method signature notation.
Compounding procedures: the least indented methods express the
greatest degree of compounding; the rightmost are orthogonal and
conceptually atomic in the ideas they convey. The rightmost
elements sequentially constitute the leftmost elements.
Functional groupings within a compound method expansion are
separated by a series of five dashes (-----).
Comments within code are signified by double slashes (//).
For example:
editNodeSet();
// the following methods define the method preceding
expandNodeSet();
// the following method defines the method preceding
addNode(); // this is an atomic method
contractNodeSet();
removeNode();
// content code
----- // this signifies a functional grouping
addContent();
removeContent();
replaceContent();
// the following methods define the method preceding
sortContent();
searchContent();
==> Data signature notation.
==> Process control notation
=----------------------
Implementation elements
=----------------------
Our design is straightforward.
==> System architecture.
----------
Motivation
----------
The heart of early design lies in creating a useful, flexible,
organized, and powerful set of interfaces. This foundation makes
the internal structure of the system transparent and allows the
system to grow and adapt. This style of design is easier to
implement, easier to debug, and easier to fix and upgrade.
------- -- ------
Vectors of change
------- -- ------
We shield the Incarna code against capricious modification by
writing layers of software, each composed of modules that
transfer control through interfaces. The routines invoked
through these interfaces can change but the interfaces can not,
so fluctuating implementations will never break a stable code
base.
The code areas where we anticipate the most flux generally are
coincident with routines supplied by commercial vendors and
those using emerging technologies. We isolate these areas as best
as possible, and direct traffic to them through a very small set
of interfaces. This diminishes the ripple of change we need to
monitor when blocks of code deprecate.
-------------
Client-server
-------------
Incarna processes execute on server and client machines. The
server is responsible for controlling the database through a
relational database management system, and for allowing other
processes (probably Java servlets and Tcl scripts) to issue
requests to the database for information. Database security code
resides at the server as well.
The client runs the display code either alone (probably as a
Java application) or in conjunction with a Web browser (as a Java
applet), and communicates over a TCP/IP HTTP, SMTP, or CORBA link
with the server.
----------
Model-view
----------
The display model is a classic model-view with four elements:
output, view, model, and database.
-- The output is a generic port for any form of rendition from
terminals and Braille readers to pagers and Sony Playstations.
-- The view is actually multiple views, one or more for each
identified visitor. The view element governs how information, in
the form of an information model, is displayed on the output.
-- The model is actually multiple models, at least one for each
state coalesced by the site and at least one for each identified
visitor. The model element governs how data extracted from the
database is treated as information.
-- The database is a relational database.
The database is the master repository of the site's content and
structure. This information is extracted to the model,
transferred (with every update) from the model to the view, which
then moves it to the output.
Three classes govern this activity: the Selector, Constructor,
and Mutator.
-- The Selector extracts data from the database for the model,
and in a variant form it picks the view and model used at a
specific moment to generate output.
-- The Constructor creates views and models for visitors or for
the Incarna system itself. In creating views and models, the
Constructor may receive data directly from a Selector.
-- The Mutator updates the database.
These classes fall into a natural hierarchy, depending on the
role they play and on whether the site under generation is
animated or not.
Selector{}
ModelSelector{}
StaticModelSelector{}
DynamicModelSelector{}
ViewSelector{}
StaticViewSelector{}
DynamicViewSelector{}
SourceVisionViewSelector{}
PersonificationEngineViewSelector{}
DataSelector{}
StaticDataSelector{}
DynamicDataSelector{}
Constructor{}
ModelConstructor{}
StaticModelConstructor{}
DynamicModelConstructor{}
ViewConstructor{}
StaticViewConstructor{}
DynamicViewConstructor{}
Mutator{}
DataMutator{}
---- ------
Code layers
---- ------
Our primary code layers look like this:
(1) The structured data system, which includes:
(A) The relational database management system, which
includes:
(i) The database security system
(ii) The data visibility control system
(B) The serialization storage systems, which include:
(i) The snapshot system
(ii) The synchronization system
(2) The site control systems, which include:
(A) The network communications systems
(i) The HTTP system
(ii) The SMTP system
(iii) The CORBA system
(B) The structured data storage system
(i) The HTML-and-XML-to-SQL parsing system
(C) The structured data extraction system
(i) The SQL-to-HTML-and-XML parsing system
(D) The structured data interpretation system
(E) The animation preparation system, which includes:
(i) The script injection system
(ii) The script parsing system
(iii) The script execution system
(iv) The email parsing system
(3) The visual rendering systems, which include:
(A) The affine transformation system
(B) The graphical user interface (GUI) system
(4) The legacy site translation system, which includes:
(A) The recursive-descent site parsing system
(5) The editing systems, which include:
(A) The node editing system
(B) The visual script editing system
(C) The persona editing system
(6) The system maintenance system, which includes:
(A) The system monitoring system
(B) The system reporting system
(7) The site content
This architecture is tentative.
==> Site characteristics.
The site absorbs and does not change data objects.
Data objects are added to a database of data objects.
Once added, objects are neither deleted nor altered.
Data objects have optional access restrictions used to limit
their visibility to defined conditions.
The data objects are connected to each other using records in
reference tables stored in a relational database. The site is
generated from the objects in these tables. The graphical
representation of the site is animated using an affine
transformation library.
As new connection patterns are established (by adding
connections or removing existing connections), the reference
table records are subclassed (copied, added as new records, and
edited in place) rather than updated or deleted. This preserves
the records of preexisting link patterns. This record base is
used to recreate previous site structures.
These steps support the site goals of dynamism, nondeterminism,
and user-controlled malleability.
==> Site objects.
These structures represent the roots, edges, nodes, and leaves of
a tree, as well as the formation rules needed to build the tree.
A Web site is nothing more than document items hyperlinked in a
subject tree. An Incarna node, for example, looks conceptually
like this:
=----------=
Nodename
------------
NodeContent
------------
NodePointers
=----------=
We identify the node by Nodename, store information in the
Nodecontent, and link along edges to other nodes through
Nodepointers. The structure supports recursion: a subsite is a
node in a top-level site. Described in the terminology that
follows, USERSITEs are SITEITEMs of the PARENTSITE.
Our site objects are:
PARENTSITE: The site as a whole, composed of USERSITEs. The
PARENTSITE is also the top-level USERSITE.
USERSITE: A USERSITE is one of many sites co-located at the
PARENTSITE and it is composed of hyperlinked nodes called
SITEITEMs. A specific USERSITE is uniquely identified by its
SITESUBJECT name. A USERSITE is represented for computation as a
tree; the SITESUBJECT identifies its root, or parent, node.
SITEITEM: A document is called a SITEITEM. All documents at the
site are identified by timestamp alone. For human use, SITEITEMs
are redundantly identified by an ITEMNAME. The timestamp serves
as a unique identifier. For human use, the timestamp is called
an ITEMSTAMP (ITEM ~= TIME, to some). A SITEITEM is text
(Unicode) or binary. A SITEITEM is a node in the USERSITE tree.
VIEW: A specific site or subsite structure as rendered by a
visitor.
SCRIPT: A document written in a programming language that
dictates the formation instructions that generate a site
structure.
VISITOR: A user of the site.
==> Relational tables.
Relational database tables constitute the Incarna backbone. The
conversion of legacy sites to an Incarna architecture is nothing
more than storing its nodes, edge relationships, and content in a
set of relational tables. From these tables, we reconstitute all
permutations of an Incarna site during its lifetime. Given a
permutation instance and a display platform target, we execute
affine transforms against the instance data to animate the site.
XML, with its rich tagging possibilities, is an ideal vehicle for
this; HTML suffices.
Our relational tables are:
(*) USERSITEITEMS -- identifies the SITESUBJECT containing each
timestamped SITEITEM at the site. A SITEITEM can be contained in
more than one SITESUBJECT. A SITEITEM can be NULL, meaning it is
part of the site's item inventory but not yet linked to any part
of the site.
Viewed another way, this table defines which SITEITEMS
constitute any given USERSITE.
-------------------------------------------------
ITEMSTAMP SITESUBJECT additional fields
--------- ----------- -----------------
ROW0 00000000 SITESUBJECT00000000 ...
ROWn nnnnnnnn SITESUBJECTnnnnnnnn ...
-------------------------------------------------
(*) HUMANNAMES -- identifies the human name corresponding to a
SITEITEM.
-----------------------------------------
ITEMSTAMP HUMANNAME additional fields
--------- --------- -----------------
ROW0 00000000 aaaaaaaa ...
ROWn nnnnnnnn zzzzzzzz ...
-----------------------------------------
(*) SITEITEMCONTENTS -- identifies the actual contents of a given
SITEITEM. CONTENT replaces the user-given name of the specific
document, which CONTENT points to.
---------------------------------------------
ITEMSTAMP CONTENT additional fields
--------- ------- -----------------
ROW0 00000000 CONTENT00000000 ...
ROWn nnnnnnnn CONTENTnnnnnnnn ...
---------------------------------------------
(*) WEBSLOTS -- identifies the position in the USERSITE occupied by
the SITEITEM. A SITEITEM may occupy more than one WEBSLOT. Keep
in mind that USERSITEs recursively occupy WEBSLOTs of the
PARENTSITE.
To locate a node, we reason as follows: A tree has left and right
branches. A left branch is represented in this table by a `0' and
the right by a `1'. We then describe the path from the root, or
parent, using a sequence of zeros and ones. This traces a path
downward from the root to the proper item.
This table identifies the locations in the site where a SITEITEM
is positioned.
---------------------------------------
ITEMSTAMP WEBSLOT additional fields
--------- ------- -----------------
ROW0 00000000 00000000 ...
ROWn nnnnnnnn nnnnnnnn ...
---------------------------------------
==> Compound data structures.
(*) ITEMSLOTS -- this vector is populated sequentially within a
given SITEITEM by pointers to hyperlinks.
The ITEMSLOTS vector represents hyperlinks in an item. The left
to right ordering of ITEMSLOT elements represents the sequence
of hyperlinks stored in an item.
-----------------------------
[link0] [link1] [...] [linkn]
-----------------------------
(*) ITEMSLOTENDPOINTS (item slot endpoints) -- this table links
hyperlink pointers to their URIs (uniform resource identifiers,
commonly called URLs).
By separating pointers and URIs, and placing all of the URIs in
one table, only the URI table needs to be updated for any
hyperlink change to take effect. Synchronization (link validity
or URI freshness) is easy to maintain using a single point of
control. It no longer is necessary to rewrite every URI in every
document following a change.
(As an aside, when a pointer in more than one item needs
resetting to a new target, we use a bulk search and replace
utility over the entire item database to find and replace it in
every instance record where it occurs.)
-----------------------------------------------------
POINTERID URI additional fields
--------- --- -----------------
ROW0 00000000 protocol://resource/aaa ...
ROWn nnnnnnnn protocol://resource/zzz ...
-----------------------------------------------------
=-------------------
Interaction elements
=-------------------
Interaction elements are the high-level tools supporting the tasks
visitors perform. Interaction elements are conveyed using screens,
or textually through the command line. The interaction elements are
what a visitor thinks of when they think of the Incarna system.
==> Element hierarchy.
Our interaction elements fall into a relatively flat inheritance
structure:
CLASS -- Animator/Time Machine
INSTANCE -- SourceVision
INSTANCE -- Personification Engine
CLASS --Editing Consoles
INSTANCE -- Nodebank Console
INSTANCE -- Personification Engine
INSTANCE -- Scripting/Definition Console
CLASS -- Injection Console
INSTANCE -- Injection Console
CLASS -- Serializer
INSTANCE -- Snapshot Serializer
INSTANCE -- Synchronized Serializer
CLASS -- Incarnator
INSTANCE -- Incarnator
==> Element properties.
Our interaction elements exhibit the following properties:
(*) Animator/Time Machine
-- SourceVision
*
-- Personification Engine
*
(*) Editing Console
-- Nodebank Console
* Output is directly transferable to the Injection Console.
-- Personification Engine
*
-- Scripting/Definition Console
* Output is directly transferable to the Injection Console.
(*) Injection Console
-- Injection Console
*
(*) Serializer
-- Snapshot Serializer
* Instantaneous site freeze.
-- Synchronized Serializer
* Transaction-completion freeze.
(*) Incarnator
-- Incarnator
*
==> Element syntax signatures.
Our major interaction elements are represented and manipulated
using a set of syntactic signatures that constitute an API.
A syntactic signature may control more than one interaction
element. Ordered alphabetically by interaction element, these
signatures are:
(*) Incarnator
(*) Injection Console
addNode();
addContent();
addLink();
(*) Injection Console in conjunction with the Nodebank Console
addScript();
animate();
freezeAnimation();
(*) NodeBank Console
editNode();
editContent();
editLink();
editScript();
(*) Node operations
getNodeName();
getContentName();
getPointerName();
setNodeName();
setContentName();
setPointerName();
editNodeName();
editContentName();
editPointerName();
addNodeName();
addContentName();
addPointerName();
deleteNodeName();
deleteContentName();
deletePointerName();
(*) Node set operations
getRealTimestamp();
advanceVirtualTimestamp();
reverseVirtualTimestamp();
editNodeSet();
expandNodeSet();
addNodeName();
contractNodeSet();
deleteNodeName();
-----
addContent();
removeContent();
replaceContent();
sortContent();
searchContent();
(*) Personification Engine
morphNodeName();
getPersona();
setPersona();
animatePersona();
freezeAnimation();
permuteFrozenAnimation();
saveFrozenAnimation();
deleteFrozenAnimation();
(*) SourceVision
startTimeMachine();
initializeTimeMachine();
advanceVirtualTimestamp();
reverseVirtualTimestamp();
-----
setRealTimestamp();
getRealTimestamp();
-----
setScript();
-----
expandNodeSet();
contractNodeSet();
(*) Unassigned signatures
setTrap();
setBreakpoint();
stepthrough();
-----
getStrobeMode();
setStrobeMode();
strobeModeOn();
strobeModeOff();
-----
sweepLinks();
validateLink();
updateLink();
=----------------------------
System classes and interfaces
=----------------------------
class Console{
Console c;
Console();
}
class Edge{
Edge e;
Edge();
}
class Itemslots extends Vector{
Itemslots i;
Itemslots();
}
class Node{
// variables
Node n;
Timestamp id;
String humanname;
String content;
Itemslots itemslots;
// constructor
Node();
// methods
isRoot();
isLeaf();
getContentSize();
}
class Nodebank extends Console{
Nodebank n;
Nodebank();
}
class NodeManager{
NodeManager n;
NodeManager();
}
class PersonificationEngine extends NodeManager{
PersonificationEngine p;
PersonificationEngine();
}
class Serializer {
Serializer s;
Serializer();
}
class SourceVision extends NodeManager{
SourceVision s;
SourceVision();
}
class Timestamp{
Timestamp t;
Timestamp();
}
=--------------------------------------
System behavior and element interaction
=--------------------------------------
These are the actions, tasks, and relationships the software
elements exhibit to a visitor.
==> Incarnator behavior and interaction.
==> Injection Console behavior and interaction.
==> Nodebank Console behavior and interaction.
-------- -------- ------- --------
Multiple linkable editing consoles
-------- -------- ------- --------
The visitor edits the site using or viewing one or more editing
consoles simultaneously. A `Node Add' operation transfers a new
node to a site, where it either is linked into the site or stored
at the site as unlinked content.
The editors are editable themselves. When more than one is
executing on the visitor display, each can, optionally, represent
a node. The visitor can connect these nodes using a mouse action
that draws a line on screen visually linking a pair of editors.
This link represents an edge; it is stored as a hyperlink.
When more than one editor is executing on the visitor display,
more than one site can be displayed and nodes can be transferred
or copied between sites or links can be established between their
nodes.
==> Personification Engine behavior and interaction.
==> Scripting system behavior and interaction.
------ ----- ----
Direct cycle mode
------ ----- ----
(a) Freeze the site.
(b) Serialize the site.
(c) Inject the serialized site into the Scripting Console.
(d) Generate the script using visual and line editing tools.
(f) Transfer the generated script to the Injection Console.
(g) Inject the script into the site.
(h) Execute the script.
==> Snapshot Serializer behavior and interaction.
==> SourceVision behavior and interaction.
==> Synchronized Serializer behavior and interaction.
=--------
Scripting
=--------
==> Scripting terminology.
Scripting, definition writing, programming, idea expression
==> Scripting purpose.
Scripts drive the Animators.
Scripts allow visitors to share personalized site perspectives.
==> Script characteristics.
Scripts are portable among platforms.
===================
Product development
===================
Information sharing
=------------------
Incarna developers congregate in a shared information space that
overlaps the system under development. This is consonant with the
design principles underlying Incarna.
The shared information includes:
Schedules
Contact information
Correspondence
Bulletins
Updates
Development tools
Reference documents (many derived from this document)
=-----------------------
Orders of implementation
=-----------------------
We exploit parallel development as much as possible. The leftmost
entries that follow are the primary development channels. The
channels are composed of the indented channels directly below them.
Each level of indentation from the margin inward represents the set
of parallel activities.
Design Incarna interaction elements
Define SQL tables
Define SQL datatypes
Define HTML file formats
Define XML file formats
Define scripts converting SQL tables to HTML for display
Define scripts converting HTML to SQL for storage
===============
Signature index
===============
Variables
=--------
Timestamp id;
String humanname;
String content;
Itemslots itemslots;
=------
Methods
=------
Constructors are noted in comments.
addContent();
addContentName();
addLink();
addNode();
addNodeName();
addPointerName();
addScript();
advanceVirtualTimestamp();
animate();
animatePersona();
Console(); // constructor
contractNodeSet();
deleteContentName();
deleteFrozenAnimation();
deleteNodeName();
deletePointerName();
Edge(); // constructor
editContent();
editContentName();
editLink();
editNode();
editNodeName();
editNodeSet();
editPointerName();
editScript();
expandNodeSet();
freezeAnimation();
getContentName();
getNodeName();
String getNodeHumanname(Node n);
getPersona();
getPointerName();
getRealTimestamp();
getStrobeMode();
initializeTimeMachine();
boolean isRoot(Node n);
boolean isLeaf(Node n);
Itemslots();
morphNodeName();
Node(); // constructor
Nodebank(); // constructor
NodeManager(); // constructor
permuteFrozenAnimation();
PersonificationEngine(); // constructor
removeContent();
replaceContent();
reverseVirtualTimestamp();
saveFrozenAnimation();
searchContent();
Serializer(); // constructor
setBreakpoint();
setContentName();
setNodeName();
setPersona();
setPointerName();
setRealTimestamp();
setScript();
setStrobeMode();
setTrap();
sortContent();
SourceVision(); // constructor
startTimeMachine();
stepthrough();
strobeModeOff();
strobeModeOn();
sweepLinks();
Timestamp(); // constructor
updateLink();
validateLink();
=--------------
Data structures
=--------------
(*) HUMANNAMES
-----------------------------------------
ITEMSTAMP HUMANNAME additional fields
--------- --------- -----------------
ROW0 00000000 aaaaaaaa ...
ROWn nnnnnnnn zzzzzzzz ...
-----------------------------------------
(*) ITEMSLOTENDPOINTS
-----------------------------------------------------
POINTERID URI additional fields
--------- --- -----------------
ROW0 00000000 protocol://resource/aaa ...
ROWn nnnnnnnn protocol://resource/zzz ...
-----------------------------------------------------
(*) ITEMSLOTS
-----------------------------
[link0] [link1] [...] [linkn]
-----------------------------
(*) NODE (conceptual representation only)
=----------=
Nodename
------------
NodeContent
------------
NodePointers
=----------=
(*) SITEITEMCONTENTS
---------------------------------------------
ITEMSTAMP CONTENT additional fields
--------- ------- -----------------
ROW0 00000000 CONTENT00000000 ...
ROWn nnnnnnnn CONTENTnnnnnnnn ...
---------------------------------------------
(*) USERSITEITEMS
-------------------------------------------------
ITEMSTAMP SITESUBJECT additional fields
--------- ----------- -----------------
ROW0 00000000 SITESUBJECT00000000 ...
ROWn nnnnnnnn SITESUBJECTnnnnnnnn ...
-------------------------------------------------
(*) WEBSLOTS
---------------------------------------
ITEMSTAMP WEBSLOT additional fields
--------- ------- -----------------
ROW0 00000000 00000000 ...
ROWn nnnnnnnn nnnnnnnn ...
---------------------------------------
========
Glossary
========
Animator
Edge
Editing Console
Graph
Human name
HUMANNAMES
Injection Console
Implementation elements
Incarna
Incarnator
Interaction elements
ITEMSLOTS
ITEMSLOTENDPOINTS
Leaf
Node
Nodebank Console
Nodecontent
Nodename
Nodepointer
PARENTSITE
Persona
Personification Engine
Scripting
Scripting Console
Serializer
Signature
SITEITEM
SITEITEMCONTENTS
Snapshot serializer
SourceVision
Synchronized
Synchronized serializer
Tables
HUMANNAMES
USERSITEITEMS
SITEITEMCONTENTS
WEBSLOTS
Time Machine
Timestamp
Tree
USERSITE
USERSITEITEMS
VIEW
Visitor
VISITOR
WEBSLOTS
=----endDocument
|
