The NetAlive System's Features
The NetAlive System's FeaturesThe following sections describe NetAlive's functions:
I. Intertasks and Self-Replication. Distribute applications among clients, servers, and peers, and manage communications between the parts of the application.
II. Development Environment. The NetAlive design tool helps write, debug, and install applications.
III. Communications Architecture (separate document). NetAlive's communcations system consisting of Netscape Client API (NCAPI) and direct Winsock access.
An Intertask can self-replicate. This property lets NetAlive aid debugging and installation in a natural and powerful way. Consider how self-replication makes the following software tasks easy:
Network software development. Say a programmer is editing a network program. Once they change one character of source, they have created a new and unique program. To debug the program, the new program has to be sent to all the computers necessary to run it. If the program is an Intertask, the self-replication capability makes this happen naturally. The application starts on the developer's computer and expands by self-replication to all the other computers.
Agents. Say a buyer wants to find the most appropriate and lowest priced product to fit some need. To do this with agents, the buyer's computer sends an "agent" computer program to a database owned by a merchant. The agent scans the database and sends the result back. However, current operating systems are not set up to execute code received over a network. However, one can set up an Intertask with both the user's front-end and the agent code for the server. When the user requests a search, the Intertask self-replicates itself to the server. NetAlive addresses and automates key issues such as security and variable instruction sets.
Software management. Computer network applications have many parts that have to be managed together in order for the application to work. For example, a Web application typically has multiple HTML pages as a front-end and multiple CGI scripts as a back end. Furthermore, there may be variants of the application depending on the browser being used. If the software changes inconsistently, the application may fail. In contrast, an Intertask makes this all straightforward: the Intertask has the application's appearance and function for both client and server. Since everything is in one entity, the parts cannot separate easily.
For the technically-minded, here are the steps involved in Intertask execution (the document A NetAlive Application's Parts describes the components of an Intertask):
Say that the Intertask in the figure below starts on host A. Host A "executes" the text box because its address is that same as A's network address. Executing a task with a widget makes the widget visible, as shown on the screen on the lower-left.
When the finishes typing into the text box, NetAlive attempts to move text "123abc" through the interconnection. However, this interconnection leads to a task on another computer. So A sends a message to B saying "do you have version 1 of Intertask file:///c|/erik/net/b.net?" If B responds with "no" then A sends B the entire Intertask. Either way, A then sends the data "123abc."
Once B has the Intertask loaded, it receives data "123abc" and puts it into the list box.
Lets say the developer changes the Intertask in the example above. What makes host B load the changed Intertask rather than continue to use the one it has? The answer lies in the Intertask's version number. The design tool increments the version number when an Intertask changes. Thus, adjusting the GUI or changing a function increments the version number from 1 to 2.
Later A will send a message to B saying "do you have version 2 of Intertask file:///c|/erik/net/b.net?" When B gets this message it kills version 1 and responds with "no." It then gets version 2 and everything proceeds as expected.
NetAlive consists of a series of system programs for creating NetAlive entities and interpreting the NetAlive format. This series includes a "full product" (or design tool) and subsets of the full product. The rationale is as follows: A design tool needs to have a viewer in it to test a design. However, many end-users do not want a design tool in their viewer. This is because unused tool commands would create unwanted complexity. NetAlive addresses this issue through a series of products that cut out advanced features at various levels.
The full NetAlive system has six interface levels of progressively more complexity. The levels form natural subsets appropriate to different types of use. The most sophisticated users will need all six levels, less sophisticated ones need five levels, etc.
Each level corresponds to a view in the standard document/view architecture. As is common in the document/view architecture, most commands are accessible only through a view. Thus, disabling or removing a view disables access to its commands. The "button bar" has icons representing views in order of complexity. A user can switch to a particular level by punching the appropriate button.
Each subset of the full NetAlive system simply disables views above a certain level. Descriptions of the different levels appear below in order of increasing complexity (the graphic is the button switching to the level).
The document level
shown below runs the application. This is the highest level in
the mini-viewer version of NetAlive
The option settings
level shown below is a dialog that accepts configuration information
for the application. Higher levels control which information collected.
For example, a news reader could use this level to let the user
enter the name and password for their subscription to a news service.
This is the highest level in the configurable mini-viewer
version of NetAlive
The constrained replacement
level presents a drag-and-drop GUI that changes the behavior of
the document within tight constraints. For example, a news reader
could use this level to customize the buttons under "sources."
The user gets a palette with all the supported Internet news sources.
They can drag any news source from the array and drop it on an
icon corresponding to a "check box." This is the highest
level in the full viewer version of NetAlive
The edit document
level shown below displays the document in its final geometry
with active resizing borders. This is the highest level in the
graphical interface builder version of NetAlive
The Intertask level
shown below displays both widget and functional tasks as icons
of a standard size. Arrows show data dependencies. A GUI permits
editing of the all attributes. This level presents a palette of
tasks, but only higher level commands can change the palette.
This is the highest level in the desktop publishing system
for online media version of NetAlive
The task definitions
level displays a dialog controlling the content of a specific
task. This is the highest level in the Network Integrated Development
Environment (Network IDE) version of NetAlive (often called
a NetAlive design tool).
Common links: | ||
 Next Section
| Previous Section
| Parent Document
|
| This is part 2 of a 5 part document: | ||
| Parts
| Features | Security
|
| Comparing NetAlive
| Platforms
| |
| This document was referenced from: | ||
| NetAlive Technology
| ||
| For reference: | ||
| Home Page
| ||