NetAlive Documentation

NetAlive Software Reuse

NetAlive supports software reuse both by the professional developer and the end-user. The professional developer can create new applications by reusing portions of existing applications. Furthermore, the professional developer can go one more step by packaging commonly-reused portions of an application into a NetAlive palette. When used properly, the palettes permit field modification by end-users.

Unconstrained Software Reuse

NetAlive uses all the tricks other software packages employ to encourage reusability. In addition, NetAlive's constraint-based nature extends these tricks to the long-delay environment of the Internet.

One requirement for today's reusable software is that the tasks must include elements of the Graphical User Interface (GUI). This is because modern GUI elements have "entry points" for keyboard, and mouse input, repainting, background processing, etc. in addition to the single entry supported by a conventional subroutine or function. Tasks in advanced programming environments (such as Visual Basic and NetAlive) attach to the GUI without burdening the programmer with an extensive set of callbacks and functions. Because tasks are left with only a few inputs and outputs, they can be replaced easily.

NetAlive's constraint-based timing deals with a new requirement for reusable software on the Internet. Other advanced programming environments continue to use a procedural abstraction for communications -- namely Remote Procedure Call (RPC). Like any procedural interface, RPC is straightforward in its response to communications delay -- the application waits until the communications completes. Since multi-second delays are not acceptable in GUI-based applications, programmers put in "hacks" to speed them up. These "hacks" defeat the modularity of the application and prevent code-reusability. In constrast, NetAlive's constraint-based nature makes a more sophisticated approach easy. Specifically, NetAlive outlines the portions of the GUI subject to a pending change in red while running the rest of the application normally. There are no hacks to limit reusability.

The theoretical issues discussed above make NetAlive's design tool useful for Internet applications. NetAlive employs the same sort of programmer's interface as other advanced tools. This refers to a palette of tasks, use of drag-and-drop for copying tasks, combining the GUI-builder into the application. The proven success of this type of interface coupled with NetAlive's tolerance of communication delay lets NetAlive achieve the same degree of code reuse for the Internet as other tools achieve on a single computer.

Typical Scenario

The following is a typical scenario for the development of a Net Alive! application: The developer thinks "gee, this is like something I saw once before" when thinking about a new application. The developer copies the application to be the starting point for the new application. The developer then looks for other applications with tasks that will evolve the application closer to the target. If such an application can be found, the tool lets the developer drag-and-drop tasks between applications. Depending on the situation, some tasks make have to be made from scratch.

NetAlive has features to regulate the reuse of tasks. These features operate by compiling (or otherwise obscuring) a task's source code.

Constrained Replacements

NetAlive leverages the developers' features described above to permit safe field-customization of Internet applications. There are many situations where an end-user changes the behavior of software without programming. Switching print drivers in an operating system or installing a modem are examples. The key to making these operations safe is a mechanism to prevent illegal modifications. NetAlive has a "constrained replacement" mode that permits fail-safe modifications of the behavior of an application.

Constrained replacement within NetAlive involves both an application and its custom palette. A developer creates an application designating some tasks as candidates for field-replacement. The developer then creates a custom palette with replacement tasks. The developer then assign tasks to classes -- replacement being allowed only between tasks of the same class. An end-user can then perform field-modifications.


[NetAlive Documentation Home Page][NetAlive Home Page]