Comparing NetAlive With Conventional Technology

NetAlive goes one step beyond conventional Internet technologies. HTML, HTTP, CGI, and Java were developed in a document framework that has been adapted for applications. In contrast, NetAlive's direct support for applications lets the designer create the best application free of historical baggage.

The following sections describe NetAlive's advantages:

I. Look-And-Feel of an Application. GUI-oriented technology gives Internet applications the familiar push-button look-and-feel.

II. Functional Power of an Application. Client-based functions let the user's computer assist in problem solving.

III. Use Somebody Else's Data. NetAlive applications can process data from anywhere on the Internet -- saving the expense of gathering data and maintaining a server.

IV. Java Versus Perl and Everything Else. NetAlive lets the designer embed the most suitable language for a given task.

V. New Applications Possible With NetAlive NetAlive applications can help users compare and contrast data from the Internet's vast body of information.

I. Look-And-Feel of an Application

Conventional Internet technology displays documents represented in the Hyper Text Meta Language (HTML) using a Web browser. HTML was designed to make paper documents easily readable on a computer. The computer displays HTML by laying-out text as if for a piece of paper as wide as the computer screen but infinitely tall. HTML extends upon physical paper with hyperlinks. Clicking the mouse on a hyperlink (typically identified by colored and underlined text) loads and displays another document. The table below shows the HTML layout in the lower-right.

In contrast, the industry bases most "problem solving" computer applications on the Graphical User Interface (GUI). Xerox Corporation developed the GUI in the 1970s as an interface for computer-assisted problem solving and it has since become universal. GUIs were never intended to be a replacement for documents -- in fact some of the earliest GUI-based applications displayed documents. Generally, GUIs present the user with a window containing a menu bar, buttons, text fields, etc., in a two-dimensional layout. Clicking the mouse invokes a command that may either change the existing GUI or switch to another one. The table above shows a GUI-style button on the upper-left.

Neither form is better than the other in absolute terms, instead developers should use each where it is most appropriate.

Conventional Internet Technology: Documents

Conventional Internet technology uses both GUIs and documents, but splits their use inappropriately. Web browsers themselves are GUI-based. Specifically, Web browsers have a menu bar, buttons, multiple windows, etc. On the other hand, Web browsers display Internet data as a document regardless of its purpose. The right column in the table above illustrates this. The inappropriate use of document in a problem-solving context is due to a limitation of the technology.

Java: Animated Documents

Documents are still documents even if they have Java byte codes embedded in them. Netscape's Navigator version 2.0 and Sun Microsystems' HotJava product both retain the document layout of HTML. Both products permit embedded Java byte codes to animate a screen region (like a graphic or large character). Java byte codes could, for example, animate the fish in the table above so it appears to be swimming. However, the page layout mechanism still applies to the entire document. The browser will "break" lines according to the current width of the browser and may scroll embedded byte codes completely off the screen.

NetAlive: GUI

NetAlive technology employs GUIs and documents where each is most appropriate. NetAlive has a new GUI-based representation for "problem solving" applications. In addition, Net Alive! uses HTML the task of representing paper. The center column in the table above illustrates this.

NetAlive stores applications on Web pages. These applications have a GUI -- a two-dimensional layout where mouse clicks invoke commands instead of simply linking to another document. NetAlive applications have all the distribution advantages of Web pages. NetAlive applications have Universal Resource Locator (URL) addresses, they are downloaded "on demand," etc.

II. Functional Power of an Application

NetAlive lets an application's designer apply the full power of the end-user's PC to helping the end-user solve a problem. Conventional Internet technology compromises on interactions with the end-user due to the document- and server-based nature of HTML technology.

Conventional Internet Technology: Hyperlinks

When an HTML document (hatched in the figure below) is too large to fit in a screen, the computer gives the user a "window" on the document (heavy border) and a scroll bar to select a location in the document. While an HTML document may interact with the user through hyperlinks ("Heading") and buttons ("look up in dictionary"), the hyperlinks and buttons scroll with the document. Unfortunately, the user can scroll hyperlinks and buttons off-screen -- making the application appear user unfriendly.

All interactions with an HTML document go through the server (except the filling-out of a form). When the user clicks on a hyperlink or presses a button, the click merely starts an activity on the server. The user's screen does not change until a message passes through the Internet to a server, the server completes a calculation, and the user's computer receives a reply through the Internet. Even if the user's action was minor, the document architecture of the Web forces a complete reloading of the document. This means mouse clicks impose a high cost in elapsed time for the user and network bandwidth. To accommodate, developers minimize the number of mouse clicks. This can make an application appear user unfriendly.

Java: GUI Within Each Applet

Java solves each aspect of the problem individually, but the solutions cannot be used together. Java can create a document with fully functional applets, but the applets cannot work together as a single application. On the other hand, the developer can put an entire application into a single applet, but this defeats the features of the browser.

NetAlive: GUI

NetAlive can scroll a portion of the screen while leaving other parts fixed. The NetAlive screen on the right of the figure above has a scrolling region ("Heading...Fish...") and a text region ("Fish: a marine animal") in fixed positions. The user can scroll the list without obscuring other part of the screen.

NetAlive can respond to mouse clicks immediately and without server interaction. In the NetAlive screen on the right, the user can click on any line in the list box. Clicking on a line invokes a function on the end-user's computer that can change another part of the screen. In the example, the application looks up the selected word in a dictionary and displays it in the text area below. This approach gives the designer a wide latitude in designing a user-friendly interface.

III. Use Somebody Else's Data

NetAlive applications can access to data located on many Internet servers and present it under control of a single application. This saves the developer the expense and effort to maintaining data without losing control of the end-user.

Conventional Internet Technology: Server's Data Only

Once the user of a Web browser switches away from a site, that site loses all control. In the figure below, a user is initially interacting with the developer's server. At this point the developer is in full control. Designers can control virtually every aspect of the user's screen. Through server logging, designers can also monitor the user's actions precisely. However, once the user hyperlinks to a third party's site, all control passes to that site.

Java: Restricted By Security

The Java "applet class" limits Internet access to the server that produced the document. In other words, say a document with embedded Java byte codes resides on server X. These byte codes can initiate Internet access, but only from server X. (This is a security feature to prevent the byte codes from moving information between servers Y and Z which may be on different sides of a firewall.) Thus, the applet security mechanism retains the server-centric control model.

NetAlive: Others' Data

NetAlive can integrate a third party's data consistently with the developer's look-and-feel, as illustrated below. The developer would make an arrangement whereby the user can access a third-party's content directly from their server. The developer's server then would have a NetAlive application for accessing the data, but not the data itself. Instead, the NetAlive application would contain a "computer program" (perhaps in a special text-processing language known as Perl) that can convert the third party's HTML look-and-feel into the developer's. Once the user downloads the NetAlive screen, the end-user's computer can get data from the third party directly.

There are numerous advantages to this approach:

IV. Java Versus Perl and Everything Else

Java implicitly assumes a "one-size-fits-all" strategy where NetAlive does not. Java's creators implicitly assumed that only one language should be embedded into Web pages. They then designed the Java language to meet these requirements. However, Java proponents have never justified the single-language assumption. In contrast, NetAlive permits embedding of many languages. Experience shows that different languages are suitable for different tasks.

Java: One Size Fits All

Embedded Java byte codes can perform general-purpose computing and the "applet class" forms an environment for input and output. Java byte codes are a binary representation of a computer program similar to the binary code of a "generic" microprocessor. These codes give the computer instructions for allocating memory, doing operations on memory, and doing I/O through calls to a the applet class (in the role of an operating system). The applet class contains entry points that permit the embedded codes to do I/O with a region of the screen and to do Internet access from the host containing the document.

Java architects intentionally limited the applet class for security reasons. Embedded byte codes cannot affect the local hard disk and may not access any Internet hosts other than the one containing the document. These limitations prevent embedded byte codes from an adversary's Web page from tampering with information on the hard disk and moving information across an Internet firewall.

The disadvantage of one-size-fits-all solutions is that they may not be optimal at anything. This applies to Java in two ways:

NetAlive: Use the Most Appropriate Language for a Given Situation

NetAlive goes beyond Java by permitting the embedding of any computer language in a Web document -- including Java. NetAlive does not constrain embedded code to be Java, but tags the code with a language specification. By following instructions in the language specification, the NetAlive run-time system can execute any language.

NetAlive currently supports over a dozen embedded languages, and each language has its strengths and weaknesses.

For example, we have found that one can make many applications that "repackage" information on the Internet. Currently, there are many sites that offer similar information but in non-comparable formats. For example, there are many "shopping malls" that offer the same product, but differences in formats prevent the end-user from easily comparing prices.

Perl is essential for a particular aspect of this. To make these applications, the client's computer must be able to access information-bearing HTML pages and efficiently separate the information from headers, footers, markup, etc. We have found Perl scripts to be an order-of-magnitude more efficient at this than any other language. Specifically, we can write a 500-character Perl script that can "filter" newspaper headlines, a list of products, etc., and convert it to a representation in a standard form.

The code below takes the headlines in HTML from the San Jose Mercury News and converts them to a "standard form." To do the same with Java byte codes would require constructing a parser using the byte codes -- which involves 100x as many bytes.

open (IN, \"$I\");
open (OUT, \"> $O\");
$Z = 1;
while (<IN>) {
    $X = 0 if s/EndHeadlines//;
    if ($X == 1) {
        $L .= \" \" if $L =~ /\\S$/;
        $L .= $_;
        if (length($_) == 0) {
            $L = \"\";
    $X = 1 if s/StartHeadlines//;
if ($Z) { print OUT \"Nothing from SJ Mercury\\tlink\\tSJ Mercury\\n\"; } 
close (IN);
close (OUT);

sub f {
    $T = $_[0];
    $T =~ s/href[\\s]*=[\\s]*\\\"[^\\\"]*\\\"/$URL = $&/ie; 
    $URL =~ s/href[\\s]*=[\\s]*\\\"//i;
    $T = $_[0];
    $T =~ s/<[^>]*>//g;
    print OUT \"$T\\t$URL\\tSJ Mercury (4.95/mo)\\n\"; 
    $Z = 0;

V. New Applications Possible With Net Alive!

NetAlive's approach enables new classes of applications not possible with Conventional Internet technology.

A NetAlive solution can assist the end-user in comparing information from different sources. A powerful example of this is finding the lowest price on a product. A single NetAlive screen can obtain prices from several suppliers simultaneously and use Perl programs to convert them into a comparable form and sort them. The user then sees them as a list. Internet data can be compared on many bases:

A NetAlive solution can integrate dissimilar information from different sources onto the same screen. Say for example that there was a NetAlive screen intended mainly as an interface to a vendor-independent drug database. Say further that vendors made safety information about drugs available directly and immediately on the Internet. The advantage of direct information from the vendor is that it might be more current. The NetAlive screen could easily integrate the vendor-direct information into a subsection of the screen.

Explore Our Site

Common links:
Next Section Previous Section Parent Document
This is part 4 of a 5 part document:
Parts Features Security
Comparing NetAlive Platforms
This document was referenced from:
NetAlive Technology
For reference:
Home Page