ALPS Display Software Architecture

ALPS DISPLAY TEAM

Contents

Here's a brief synopsis of what follows:

• Overview:  Introduces the ALPS display software architecture.
  
• Goals:  Elaborates on what we hope to gain from this effort once the dust settles.
• Current Architecture:  Diagrams and explains what the AWIPS display architecture looks like right now.  It's presented here since the proposed architecture will derive heavily from it.
• Proposed Architecture:  Diagrams and explains what we hope to build.
• Implementation Strategy:  Outlines how we will incrementally construct the new building blocks in this architecture and integrate the new pieces with the existing components.

Overview

These overview sections amplify the title of this document by explaining what is meant by software architecture, display software as opposed to ingest software and the ALPS project and how it evolved from the AWIPS project.  The last overview section describes the basic structure of both ALPS and AWIPS architectures from a requirements perspective.

What is Software Architecture?

Legend for Architectural Diagrams

Building Blocks

• Executables:   These can be either executable scripts, compiled programs or a combination of both.  For example, the D2D user interface is implemented by Tcl/Tk scripts that are interpreted by an executable that is capable of executing the entire Tcl/Tk command set as well as a set of customized commands.
• Storage:  These store meteorological data or meta-data (data about data) and can take on numerous forms: a NFS mounted directory of flat files, a relational database, or a hardware storage device such as a RAID disk array.
  
• Reusable Libraries:  These are defined to be a collection of modules which implement a fixed set of functionality accessible through a well defined programmer's interface.  These libraries are general enough so they can be used in a wide variety of applications.  Generally, these libraries are self-contained and don't depend on other library code except for basic system libraries like libc.  The X, Informix, and NetCDF libraries all fall in this category while most current AWIPS libraries do not.
  
• Executable Components:  These are a collection of modules, classes, or non-executable scripts grouped together to satisfy some subset of an executable's mission.
  

Conduits

• TCP/IP Sockets:  Implements the communication medium between two processes running on the same host or different hosts on a local or even wide area network. TCP/IP is actually two protocols or rules of engagement (Transmission Control Protocol and Internet Protocol) that form the basis of the Internet. TCP/IP is widely used in AWIPS and will be in ALPS because of its reliability and ease of use.   A process can quickly tell if the other process has closed its end of the connection, or if there is any trouble with the connection.  Also, the socket which refers to the connection's terminus can be read and written like any other block file device.
  
• I/O Pipe Redirection:  Is another way to implement interprocess communication (IPC) by redirecting the input and output channels of two processes to the ends of a pipe device.  This has the advantage over sockets in that it is easy to integrate with external programs.  The external program writes a text message to its stdout channel to communicate to the host and receives a message from the host by reading its stdin channel.  However, this approach presents some significant limitations.  IPC is limited to the host and the stdin and stderr channels now serve a very different function than what most code assumes.  For these reasons, the ALPS display architecture will probably not employ this type of conduit.
  
• NFS Access:  The Network File System (NFS) provides a way for an executable to access data stored on various hosts and storage devices that are accessible anywhere on the local  area network.  With NFS, the interface for accessing a remote file is identical to accessing a local file except for the caveat that there may be some performance hit or reliability issues when accessing a remote file.
  
• Component Communication:  The communication approach between components of an executable will vary tremendously depending on the components involved.  The mechanisms could be calls to C/Fortran routines, a shared global data structure, C++ inheritance and/or polymorphism, a design pattern, or Tcl/Tk code invoked from C/C++ via the Tcl_Eval() routine.  In our discussion of the architecture, we will be focusing more on the relationships between components rather than the implementation of the communication mechanisms.
  

Display/Ingest

The current AWIPS architecture from its inception has been split into two development areas, display and ingest.  Ingest software obtains a wide assortment of meteorological data from various sources, notifies display processes when new data arrives and also purges old data from the storage devices.  Display software is the set of visualization and GUI tools that provide forecasters with a porthole into the huge assortment of data that the ingest system provides.  The display system also includes a powerful set of scripts that can easily change the geographic area that the software is localized for.  Both development areas have well defined boundaries; for example, display and ingest software run on different kinds of hardware.  But there is a lot of overlap between the two types of software and the development teams that produce them.  For instance, both ingest and display software rely on common support libraries maintained by both teams.  This document will primarily cover the architecture of display software, but will mention components of the current and proposed ingest system as they relate to the display.  For a much more detailed description of the proposed ALPS changes to the ingest system, see this description of the distributed data concept.

Brief AWIPS History

ALPS

In February 2004, FSL developers and managers participated in the inaugural design meeting of the Advanced Linux Prototype System (ALPS).  The goal of that meeting was to decide what was to be accomplished in one to two years time.  Sandy MacDonald kicked off the meeting by stressing that any FSL-contributed enhancements to AWIPS should be addressing the anticipated future trends of the National Weather Service (NWS).  One such trend that Sandy elaborated on was the concept of system convergence where forecast operations become far more portable based on weather and other considerations.  Simply said: any job, anywhere.  In order to move in this direction, certainly the system has to perform well in all aspects and decommissioning the HP-UX workstations will alleviate some of the performance bottlenecks.  But the system also has to be easily adaptable for different uses without adversely affecting performance and will need some excellent collaboration tools so remote forecasters can work together effectively.  In addition, the ingest system will now have to provide access to display-ready data that has been generated elsewhere.  Since considerable software changes will be needed, now is an excellent time to reevaluate our architecture so that it satisfies the NWS requirements of today and tomorrow. 

Several members of the original AWIPS display design team and the developer of the GFE display engine have teamed up to rework the AWIPS display software with the dual intention of significantly improving user response time while providing a usable mechanism for adding functionality from an external  executable.  In coming up with a plan of action, we considered a handful of different approaches.  One extreme is to keep the existing architecture and hack the current extension interface and display engine with baling wire and duct tape in order to develop an extension that could do some level of collaboration.  The other extreme is to throw out the current architecture and develop a new general purpose display engine and all the current and future display capabilities would be rewritten to use the application programmer's interface (API) into this display engine.  We also considered hybrid approaches that gravitated somewhere in the middle of those two extremes.  After a week of design meetings, we hashed out the proposed display architecture being presented in this document.  At the end of the week, all of us felt that this middle of the road approach could address some, but not all, of the performance issues.  Just as important, this would give us a display architecture that will allow an average C programmer with no knowledge of the display software details to add significant functionality to the display software.  And perhaps, most important of all, this is something we feel we can implement in the time allotted.

Architectural Requirements

While evaluating an existing architecture or inventing a new one, it is useful to identify the high level requirements that the architecture supports.  Then those can be defined in terms of high level building blocks and conduits which can in turn be decomposed into lower level building blocks and components.  Both the ALPS and AWIPS display systems have these extremely basic requirements in common.

• Data Access:  The display system needs to access meteorological data of different varieties such as satellite, grids, radar, obs, raob, etc... in a format that the display software can work with.  Since most data is time sensitive, the display software also needs to access a data set's time inventory and be notified when new data arrives.  This requirement is handled by the ingest software and architecture and is included here only because the display system will interface with some of ingest building blocks for this requirement.
• Data Selection and Interaction:  The user of the display system will select products to visualize and control their display characteristics from a sophisticated and easily configurable graphical user interface (GUI).  Display characteristics are quite diverse; attributes like the time matching, the density of the product's display, an image's color table, display domain, animation parameters, etc...
• Data Visualization:  The main point of the display system is to visualize different data sets together in a variety of different kinds of visual representations such as a time series or cross section graph, a plan view contour, wind barb or image plot, a sounding diagram,  etc...  These visualizations can be rendered for display using the host's graphics hardware or rendered to a Postscript file for printing purposes, or to an image file or graphics metafile for collaberation purposes.  The software must ensure that the different data sets displayed together match reasonably well in time.
• Display Access:  Since this is an interactive graphic system, the software must be able to display complex graphics and images on platforms with multiple display heads and also receive input via keyboard and mouse devices.
• External Functionality:  The system must provide a mechanism that additional user interfaces, visualizations or new functionality can be added outside of the core software but still be tightly integrated with the basic display system.
  

Goals

Every successful project identifies its achievable objectives before commencing and the ALPS project is no different.  The following sections describe what the ALPS display team hopes to accomplish by the end of the project.

Improve Extensibility

An extensible architecture provides developers with an opportunity to extend the functionality of a system at a later date without compromising the infrastructure.  An effective tactic for protecting that infrastructure is to confine adaptations and extensions to external executables that run beside the base system.  Ideally, these enhancement developers shouldn't have to know the intimate details of the underlying architecture and shouldn't be restricted to developing in a specific programming language.

The AWIPS display software was retrofitted with two distinct extensibility mechanisms, the application and extension interfaces.  The application interface is a way for an external program to query and control the contents and parameters of the large display pane of D2D.  Application programs can perform actions like load or unload products, query the color table used to display the image or step to the next frame.  The extension interface is a way for an external program to display simple graphical objects with the user loaded products inside a D2D pane.  An extension program receives notification from the display engine when the user interacts with the extension's objects.  When these interfaces were brand new, most of the applications and extensions currently existing were written by the same developers who wrote the interfaces.  The hope was that over time, developers from all over the NWS community including forecasters would write extensions and applications.  What has happened instead is that very few applications/interfaces have been written and the functionality and complexity of the two main display executables (fxaWish and IGC_Process) have increased steadily.  If we are to have any chance of improving extensibility, we need to understand what went wrong with the current design.  Here are the most glaring defects and how we will be addressing these with the ALPS architecture which is built around the concept of plugins.

• A developer that is extending AWIPS needs to write two separate programs if she needs the functionality of both the application and extension interfaces.  ALPS will support separate interfaces providing similar functionality to the extensions and applications, but these interfaces can be all linked together in the same executable.  For example, an ALPS plugin can draw and interact with a graphic that it derived from exporting the data of a user loaded product. 
  
• AWIPS application and extension interfaces are extremely thin and inconsistent, containing barely enough functionality to support existing external executables.  For example, the application interface has a way to set the preferred frame count, but no way to query it.   The extension interface has a way to label objects with text, but has no way of creating free standing text.  ALPS interfaces will be designed without a particular program in mind, and will try to be as complete as possible.  ALPS will probably evolve to have different levels of interfaces:  a basic drawing interface will be provided first and then later an interface that draws meteorological entities such as fronts may be developed on top of the elementary drawing interface.
• AWIPS applications have to give up their standard in/out channels in order to communicate to the base system.  All ALPS plugins will link with a simple communication library that the base system will communicate with.  The details of this library will be completely transparent to the ALPS plugin developers, and will not monopolize any of resources usually available to a program.
  
• The AWIPS extension interface is rather complex and requires familiarity with object oriented programming.  All ALPS interfaces with be initially written in C and tools like SWIG will be used to generate wrappers for other languages.  An effort will be made to keep the interfaces fairly simple and well documented.
  
• AWIPS extensions and applications are tedious to integrate into the base system.  In most cases, developers must modify several different meta-data tables.  ALPS plugins will have an introspection capability.  A plugin developer simply has to drop the plugin into a directory dedicated for plugins, and the base system will ask the plugin questions about itself, which will provide enough information to make a menu entry for it, or for any other required table entries.
  
• AWIPS extension executables require linking with eight AWIPS support libraries, some of which are fairly dense and contain code that will never be needed by extensions.  In general, an ALPS plugin will link with just the interfaces it needs, plus the comms/support library.  For example, the volumeBrowser plugin will link only with a base plugin library and the interface for loading data since it doesn't need to draw its own graphics/images to the display.
  

Plugins

Simply defined, plugins provide some specific functionality to a larger system but are developed separately and typically run in their own process space.  If done correctly, plugins are integrated so seamlessly that the user is completely unaware that this functionality came from another program or development organization.   The real strength of the plugin concept is that all the communication protocols between plugin and host application are completely defined and documented through an easy to use and flexible application programmer's interface (API) which insulates the plugin writer from the implementation details of the host system.  Plugins should be a familiar concept to most computer users: most of the popular browsers, office suites, image manipulators, and multimedia players use plugins to augment their functionality.

In AWIPS, we do have external programs that supplement functionality outside of the AWIPS framework.  However, these applications and extensions are missing one key component of the plugin concept: these programs are difficult to develop by outside organizations due in part to the absence of a usable API.  There are other problems with extensions and applications listed above in the previous section.  The ALPS plan is to revise the current display architecture to support plugins which includes developing a clear, concise, and usable API (at least usable by an average software developer from any organization).  The current applications and extensions will be converted to plugins by reusing as much of the original code as possible, but rewriting the interfaces to use the new API.  We will also be testing out the plugin concept by encouraging developers who aren't on the display team or even at FSL to try out the new API and write plugins that introduce some kind of new functionality into the system.

Similar to the way extensions work now, each plugin will be given its own overlay (if it asks for one) in which all the plugin's graphical output will be combined with other product overlays.  Plugins will be able to at least do everything that current AWIPS applications and extensions do, plus some additional capabilities that are not available to current AWIPS external applications.  Here are some of the key new capabilities we plan on adding.  Hopefully in the future, we will be adding to this list in order to make plugins even more powerful.

• Complete the current application interface of loading/unloading/exporting data, and setting/querying scale, display, frame, and time-matching properties.
• Much more direct control of mouse and keyboard events than current extensions.
• Ability for a plugin to draw images and many more primitives than the current extension interface, including multi-colored primitives.
• Use plugin introspection instead of table entries to control how the plugins should be presented on the D2D menus or loaded into the display.
• Plugin will be able to add entries to the popup menu dedicated to its overlay.
  

Reduce Redundancy

A display system that is extremely responsive to a user's interactions has always been a goal of AWIPS.  However, performance has sometimes taken a back seat when trying to keep pace with providing the needed functionality and reliability.  This may explain why the architecture has evolved into a small handful of extremely large executables which run as processes that consume a considerable amount of physical memory and CPU cycles.  One such executable, IGC_Process (aka IGC), provides all the visualization and GUI inside a D2D pane.  On a host with a three headed display, 15 IGC processes could be running.  On an OB5 test platform, an IGC loaded with a 32 frame loop of IR combined with Visbile consumes 140MB of memory (7.5 for code and the remainder for heap/stack storage) and 11.95 CPU seconds  to initialize the process and load the loop.  A host may be displaying a handful of panes with heavier loads than this one and also be running processes that manage three instances of the D2D GUI and multiple instances of warning generator and the volume browser.  A host with this load will have very busy CPUs that are not only executing AWIPS code but also swapping between virtual and physical memory.

One way to optimize performance is to upgrade hardware with faster and more processors, and more physical memory.  This approach is attractive in some ways since software development costs often exceed hardware costs.  However, if the software continues to remain bloated and place efficiency at a lower priority, eventually a hardware performance ceiling will be hit.  Besides, it makes more sense to reserve the performance benefits of additional hardware for supporting future growth such as additional data sets or functionality.  Finally, to truly support the idea of "any job, any where", upgrading some sites with high end hardware may not be an option.

Another way to increase system throughput is to reduce the stress on the host's resources.   This can be done by factoring out redundant tasks that multiple processes perform, each consuming processing and memory resources.  The alternative is to have a server process perform these tasks only once, and then serve the results to leaner processes that no longer have to carry extra code or consume memory or CPU cycles in order to satisfy these common tasks. 

The ALPS display and ingest architecture will incorporate this approach by factoring out the tasks of computing inventorys and accessing and preparing data for display from the multiple IGC, volumeBrowser, or future plugins that may require these services.  This code will be moved to server processes that may have only one instance per host or maybe even serve the processes from several hosts across the local area network.  The proposed architecture description introduces two of these servers, InventoryServer and DepictServer but many of the details of these new components still need to be worked out.

Support Multiple Motley Colored Overlays

The AWIPS display engine (IGC) organizes its D2D pane by rendering each product in its own layer or overlay except for overlays holding a combo image which is filled with two products.  Under normal operation, the IGC renders all the visible overlays (overlays can be hidden) into the entire D2D pane which is an X Window.  The IGC can also be in a mode where the pane is evenly split into four panels which are also X Windows.  For each panel, the IGC renders a subset of the overlays that are assigned to that panel.  IGC supports overlays that can support a wide array of colors and also overlays that are limited to a single color.

Single-colored overlays contains vector graphics and bitmaps used to visualize graphical objects like text, wind barbs and arrows, contours, symbols, warning boxes, etc.  Contents of the overlay are all drawn in the same color even though this color can be specified interactively.   An important characteristic of these overlays is that they are rendered so that the background appears transparent.  This attribute makes it possible to display more than one single-colored overlay in a panel.  These types of overlays will probably still be supported under ALPS.  If there was a way to display more than one multicolored overlay, certainly some products that are displayed today in a single color could be enhanced considerably from a large color palette.  However, many products will still only need a single color for their depictions, and displaying these in a simple single color overlay consumes much less storage and can be rendered, toggled, and color-adjusted quicker than their motley colored counterparts. 

Multiple-colored overlays are used to visualize both images and vector graphics.  The word image has lots of meanings but here we are simply referring to a sequence of pixel values that covers a rectangular area.  In our case, the area completely covers either a D2D pane or panel.  AWIPS and ALPS allow the pixel values to be either a single byte indexing a color table entry (pseudo-color) or four bytes that specifiy the RGB color components (true-color).  Unlike the vector graphics in single-colored overlays, there is no restriction on the number of colors used to depict the vector graphics inside a multicolored overlay.  Profiler and orographic snow plots are two examples of vector graphic products that are currently displayed in multicolored overlays.

The current IGC does not support background transparency for its multicolored overlays which leads to the unfortunate constraint that a panel is limited to displaying only one multicolored overlay.  An IGC can display several images or multicolored vector graphics simultaneously but each one of these either has to be in a separate panel or combined together in a single overlay.  We called this an unfortunate constraint since one could think of a handful instances where overlaying many images or motley colored graphics on top of each other could be very desirable.  For example, one of the lightning plot products contains strikes of different colors which show how old the strike is.  It is very conceivable that a forecaster would want to see this product on top of a radar image.  However, because of the limitation of being able to display only one multicolored overlay, the lightning product is displayed not as a multicolored graphic but instead by splitting it into a handful of single-colored overlays, resulting in an overlay and an associated legend for each possible strike color.  This not only clutters the display with extra legends but means that a forecaster can't toggle, unload, or magnify the lightning product at once; she has to operate on each strike color individually.  It is not far fetched that a forecaster might want to view a Z/SRM combo on top of a topography image or an overlay containing various colored fronts and symbols from a plugin that supports collaboration between two sites.  Both these scenarios would be possible if AWIPS supported multiple motley colored overlays.

Minimize Rewrite/Disposal of Existing AWIPS Code

Equally as important as reaching the above three goals, we need to reach them in the time frame of the ALPS project (currently two years) and still provide the current functionality of the current AWIPS display software system. 

A much more radical change in architecture was given serious consideration by the ALPS display team.  This idea was to rip all of the display management code out of the IGC and into a much more generic, highly optimized display engine.  This way we could design the display engine from scratch using the latest rendering techniques.  Possibly the engine would be implemented to use OpenGL or some other graphics library.  The depictable classes which access the data and transform it into graphics instructions or pixel arrays would be moved out into another process and use a standard application programmers interface (API) to access the display engine.  What would be left in the IGC would be code that manages the time management of products and would also use the same API.  The same API would also be used by plugins.  This seemed feasible until we started delving into the details.  After a few days into our design meetings, we realized that the IGC did much more than we realized.  Figuring out how to support features like the four panel display, roaming, legends, sampling, popup menus in the API and the display engine made us all dizzy.  We quickly realized that implementing this particular architecture would involve rewriting a great deal of existing code which didn't directly address the performance, extensibility, or overlay limitations that we identified as our goals.

It was then that we decided to reuse the IGC as the ALPS display engine.  In order to improve extensibility, we talked about transforming extensions and applications into plugins, but hopefully the core code that makes up these external programs will be reused as much as possible.  Eventually the depictables will be moved to another process, but this could be done so that the interfaces between the IGC and the depictable are basically the same, just adapted to work across process boundaries.

Current Architecture

The following diagram and sections describe how the AWIPS display software is organized into the various building blocks and conduits that implement the high level requirements.  A note to the reader:  this section is a shameless oversimplification of a substantial body of software.  It represents only the big picture; many of the details have been omitted.  WFO Advanced Overview written in 1997 is still an excellent resource for architectural and implementation information.  Chapters 8, 9, 10, 11 cover the components of the display architecture that we will briefly discuss here.

Data Access

Every site has their meteorological data stored on some kind of hardware storage device accessible through an NFS mounted directory whose pathname is stored in a global environment variable, FXA_DATA.  This form of data access doesn't facilitate sites easily sharing data with each other.  AWIPS also has the complication of the NFS storage device managed by the HP-UX OS while the executable that is designed to access the data, IGC, runs on Linux workstations.  This platform interoperability produces some strange NFS file synchronization problems.  The data in this NFS mounted directory can be in three different storage formats; the three most common used in AWIPS are binary flat files, NetCDF files, and data accessed through an Informix relational database.

The notificationServer executable implements the critical capability of notifying certain display executables when there is new data for registered products.   The data selection executable (fxaWish) registers for the products on the selection menus while the data visualization executable (IGC) registers for each product loaded into its display pane.  The ingest decoder processes send messages to the notificationServer once they write data to the $FXA_DATA directory.  The details of the notificationServer are not given here since it is considered part of ingest software.

Display Access

X11

To write software from scratch to rasterize a line and display it on one of the monitors can certainly be done, but fortunately we don't have to reinvent the wheel.  There are many software packages that mediate an application's access to the host's multiple displays, graphics processors and memory (aka frame buffer) and input devices such as the keyboard and mouse.  One of most ubiquitous of those packages that run on variants of Unix platforms is the X Window System, Version 11, or better known as X11.  This package has been around for over 20 years and has matured tremendously over the years.  One of its biggest strengths is that all applications or clients deal with a highly optimized server executable called the X Server through a very complete and fairly easy to use (subjectively speaking) API known as Xlib. Communication between server and clients is via TCP/IP sockets and thus with X11, it is very common for a client to execute on one host and display on another in a local or even wide area network.  The other strength of X11 is that all the clients have to play by the same rules (there is no preferential treatment, not even for window managers); one client can't monopolize the graphics resources of a host.  If there is a disadvantage to using X11, it probably is its general nature (which is also a strength).  Through X11, it is very difficult to take advantage of a particular feature of a graphics card, like translucency.  However, that situation has improved over the years since more and more extensions have been added to X11 to access advanced graphics features.  The shape extension is a prime example.

Tcl/Tk

Data Selection and Interaction

The AWIPS display architecture has designated one executable, fxaWish, with the burden of implementing the look and behavior of the D2D GUI.  The GUI is primarily an intricate menu system that can be completely configured from several text files.  These nested menus select a product to be viewed in a display pane or an application or extension to be run.  The menu buttons with time sensitive products will contain the time of the latest data for this product (aka green time), according to the notificationServer. This GUI also has various widgets: option menus, toggle buttons, and dialog boxes, used to specify the various time and visualization characteristics of the products being viewed.

In addition to implementing the selection and interaction GUI,  fxaWish divides the available display area into multiple panes and assigns each one to an IGC process.  The layout usually consists of four smaller panes on the left side next to a larger pane on the right.  For simplicity sake, the D2D menu and tool bars interact only with the large pane.  Each pane is actually an X Window that the IGC will use as its canvas for all of its visualization and user interactions.  fxaWish can't draw into these panes directly or solicit its interactive events, but it can resize these panes since the user is allowed to adjust the pane layout.  It can also instruct an IGC to use a different pane in order to support the user capability of swapping the contents between a selected smaller pane on the left with the larger right most pane. 

fxaWish is a specialized wish interpreter.  Wish is a program included in the standard Tcl/Tk distribution which interprets and executes scripts containing Tcl and Tk commands and is usually adequate enough to run some very complicated applications.  Yet, much of the support code that fxaWish requires has already been written in C/C++ and it is quicker to write Tcl/Tk interfaces to execute the C/C++ code than it would be to write the same functionality from scratch in Tcl/Tk.  A script that is interpreted with fxaWish has access to all of the Tcl/Tk commands plus a wide variety of commands supplied by AWIPS support code implementing services like logging, configuration, and IPC.  C/C++ inside fxaWish can easily execute standard Tcl/Tk commands or even code from the script being interpreted.   Here's more detail about the underlying structure of fxaWish:

• D2D Tcl Scripts:  A huge set of collaborative Tcl/Tk scripts that define the layout and behavior of D2D's menu bar, tool bar, status window, the display panes, and the helper dialogs such as the complex printing and color table editing dialogs.  This code is also responsible for parsing the text tables that design the structure and contents of the menus used to load products, extensions, and applications and defines a callback triggered from the notificationServer which updates a product's green time.  Many of the GUI interactions will result in a message being sent to the IGC managing the large pane,
  
• IGC Proxy: This module handles communication between the D2D Tcl/Tk scripts and the IGC processes.  Usually, the message is sent to the IGC currently assigned to the large pane, but sometimes a message is broadcasted to all IGCs.  This code is also responsible for starting/stopping and restarting IGC processes.  Much of the logic for swapping IGC panes is also inside here.
  
• Workstation Mgr: The D2D GUI tries to reflect the actual display parameters being used in the large pane when presenting dialogs to change those parameters.  This module receives constant updates from the IGC running in the large pane as to what its display state is.  These state values are then passed on to the D2D Tcl/Tk scripts by way of registered callbacks. 

Data Visualization

The AWIPS display architecture has designated one executable, IGC_Process or commonly referred to as the IGC (Interactive Graphics Capability), with the massive burden of visualizing meteorological data (satellite images, station plots, radar, gridded model graphics, soundings, etc...) inside a pane that has been allocated by the fxaWish executable.

IGC operates in two display modes, single or multi-panel.  During single panel mode, the IGC uses the entire display pane as its visualization canvas.  As mention earlier, a conceptual display pane is nothing more than an X Window to which the software can render vector graphics and images and solicit input events like mouse clicks and drags.  The IGC uses that mouse input to deliver the zooming, roaming and sampling services inside the display pane.   The IGC can also be instructed by the user directly or by the fxaWish executable to transform into a multiple panel mode.  This results in a layout of multiple, contiguous X windows, stacked directly on top of the display pane window.  Each one of these is called a panel, an unfortunate name because it often gets confused by the term, pane, which refers to the entire display area that the IGC is managing.  Technically, the software supports a layout of any number of panels, configured in a variety of different rectangular shapes.  However in practice, AWIPS only supports a four panel mode, where the display pane is equally divided into four panels.  This mode is commonly used to view the same radar at different tilts.   Each panel has both autonomous and dependent characteristics.  Products can be loaded independently in different panels, and each panel has its own list of legends and popup menu system.  However, panels zoom, roam, and sample together (which is possible because each panel's cursor is linked to each other).

IGC spatially organizes the products it is currently rendering into overlays.  The first product with a valid data inventory loaded into an IGC after a clear will be represented as the primary overlay.  The primary overlay is special since its time sequence will be used by the time matching alorithims to derive the time sequences of all subsequently loaded overlays.  An overlay has the following traits associated with it:

• A set of panels that it is being displayed in.
  
• Visibility state.  Overlays can be visible or temporarily hidden by the user.
• Whether it supports single or multiple colors.  If only a single color is used to render it, then the overlay has an RGB (red, green, blue) triplet attribute which can be changed by the user.
• If the overlay displays vector graphics, the following attributes apply: line style and width, magnification and density.
• If overlay displays an image, the following attributes apply:  color table that maps pixel values 0-255 to RGB triplets, brightness and fade (applicable only to combo images).
• Time sequence which is derived from the product's inventory and time matched against the primary overlay's time sequence.  Static overlays don't have a time sequence since the associated product's data is not time sensitive, like the data for map backgrounds or some extensions.
  

IGC temporally organizes the products it is currently rendering into frames.  A frame is a sequence of depictable objects belonging to different overlays where each depictable has a data time that is compatible with the other depictables in the frame.   The number of frames is the smaller value of either the user's preferred frame count or the number of times in the primary overlay's time sequence.  The same frame is always displayed in each of the IGC's panels and a panel can only display one frame at a time.  By default, the frame with the latest data is displayed but different frames can be selected through user interface or by the expiration of a timer which is the case when looping is active. 

Now that the concepts of pane, panel, overlay, depictable and frame have been introduced, here's a general overview of how the IGC displays itself.  One of the AWIPS requirements is the ability to loop frames of data very rapidly.  The IGC makes this possible by using off screen preparation, which is a very old computer graphics technique.  X11 supports this quite nicely with its pixmap resource.  A pixmap is memory allocated in the X Server process space; the same interface a client uses to draw inside a window is also used for a pixmap.  The difference is that client's drawing is displayed almost immediately inside a window while the pixmap is not displayed until the client explicitly copies it to a window.   Each panel (or the main pane, if in single panel mode) is allocated a set of pixmaps, one for each frame with the size of the pixmap matching the size of the panel window.  To prepare a frame, IGC calls the paint method of each visible depictable (visiblity is an attribute of the overlay that the depictable belongs to).  The parameters to paint() mainly specify the display characteristics of the overlay like line style and density and enough information for the depictable to convert between world and display panel coordinates.  The parameters also specify the canvas that the depictable should draw to which varies depending on whether the depictable's overlay is single or multicolor.  The depictable will then access its data if necessary and use a Painter object to draw its depiction on the specified canvas.  For each panel that the depictable will be displayed in, the canvas contents are copied to the panel's pixmap associated with the frame to be prepared.   Copying the output of the depictable to the pixmap is straightforward in some cases and very tricky in others since color enhancements are often applied here as well.  This is where the IGC has taken some short cuts which has led to the limitation of displaying only one multi-colored overlay in a panel.  Once all the depictables in the frame have been rendered, the frame is now prepared and can be displayed very quickly by assigning each panel's pixmap associated with the frame to the background of each panel's window, and then clearing each window.  On the down side, off screen frame preparation significantly increases the X Server's memory usage.  But on the plus side, the preparation of frames not being displayed can easily be done while the IGC would normally be idle waiting for X and IPC events.

Here's a brief summary of the IGC's major components:

• DisplayMgr:  Collection of C++ classes that provide the following services: 
  

1. Displays the output of all visible depictables associated with a frame along with legends, samples, and special cursors into a single or multiple display windows using the off screen frame preparation method.  To support this, the necessary X Server resources such as windows, pixmaps, fonts and cursors are allocated and deallocated as needed.
   
2. Receives and interprets the mouse events inside the IGC's display area and dispatch these events to other IGC components.
3. Receives and executes external commands from the fxaWish executable that affect the appearance of the D2D pane such as the panel layout or background color.  If the IGC is  assigned to D2D's large pane, messages are also sent back to fxaWish so it can keep its GUI synchronized with the display attributes of the large pane.
   

• FrameSeq:   Collection of C++ classes that provide the following services: 

• PopUpMgr:  An assortment of integrated C++ and Tcl/Tk code that implements a context sensitive popup menu system.  Popup menus are invoked by mouse button 3 whose X event is passed to this component from the DisplayMgr component.  Popups invoked over a legend will contain entries for changing the attributes of the overlay associated with the selected legend.  If not invoked over a legend, the popup can used to set properties of the panel or for zooming or unzooming.   This component accesses the FrameSeq and DisplayMgr components to set and query the various attributes of the IGC.

• Depictables:  An enormous C++ class library that does most of IGC's heavy lifting.  Depictable objects are constructed and destructed by the FrameSeq software.  This component also invokes the two virtual methods that every depictable has in common.  The paint method has already been discussed: it triggers the depictable to read its data, use the display and coordinate mapping parameters to transform the data into a depiction, and finally paint that depiction into the specified canvas.  More often than not, that canvas will be either a byte buffer or a bitmap (pixmap with a depth of 1) but can also be a graphics meta-file or a Postscript prolog.  In order to simplify the depictables, the actual details of writing to a canvas are encapsulated inside the Painter objects.  The other key interface is the interrogate method which is called by the FrameSeq while the DisplayMgr is assembling the sample text for a particular cursor position.  The interrogate method is passed both a display and world coordinate and it returns a text string representing the depictable's interpretation of the data value for the specified location.
  

• Painters:  Class hierarchy used primarily by depictable objects that hides the details of rendering vector graphics and images into a variety of different devices or canvases.  Currently, AWIPS supports these kinds of painters.
• XPainter:  Uses X11 interface to render into a pixmap.
• ImagePainter:  Renders into a buffer representing a rectangular region.  Each buffer element holds a byte (i.e. a value between 0 and 255).
• PSPainter:  Renders into a Postscript prolog file for printing.
• DGMPainter:  Renders into a home grown graphics meta-file format.

• ExtMgr:  Several classes that launch, terminate and restart extension processes and manage the communication between them and the IGC.  The initial request to launch an extension is from a standard load request processed by the FrameSeq classes.  These classes obtain the information necessary to launch extensions from a text table.

• Interactive Depictables:  Sequences of a special derivation of a depictable object; each active extension has its own sequence.  Like other depictable objects, it provides an implementation for both the paint and interrogate methods.  Unlike other depictables, these don't access data inside an NFS mounted directory pointed to by the $FXA_DATA environment variable.  Instead, these contain objects called editable elements which are simple vector objects that can be manipulated by the user.  Another difference is that every interactive depictable has a corresponding interactive depictable in an extension process.  Corresponding depictables should always be mirrors of each other.  If an editable element is added, deleted, or modified in an interactive depictable, the corresponding interactive depictable in the other process should be updated with the same change.  This involves a lot of IPC between the IGC and extension processes!  The biggest difference between these depictables and the more conventional kind in the depictable library is that these depictables are sent X events that arrive through the DisplayMgr which are used to edit the elements.  Interactive depictables don't use a painter object for its rendering, accessing X11 directly instead.  Thus, interactive depictables can't be exported into a graphics meta-file or a postscript file like other depictables can.  
  

External Functionality

AWIPS provides two different mechanisms for a developer to extend AWIPS functionality outside of the core display executables: applications and extensions.  Both of these mechanisms have shortcomings already discussed in the extensibility goal section.

Applications

The application mechanism provides a way for external programs like the volumeBrowser and rps (RPS List Editor) to extend data selection and interaction or to export displayed data into some graphics meta-file format.

When an application is selected from the D2D GUI, a message is sent to the appMgr process which checks to see if the desired application is running.  If not, the appMgr reads a table describing the application and its attributes and then launches it.   Applications interact with AWIPS through a simple set of text string commands with each command having its own argument list.  All commands are preceded by the string, "@@-" and are passed through a duplex connection between the application, the appMgr, and fxaWish using the i/o pipe redirection approach.  Since commands are always relayed through the appMgr, applications will not interact with AWIPS if the appMgr executable fails.  This text command interface makes it possible for applications to be developed in any language.  Currently, AWIPS provides applications commands for operations on the main D2D display pane such as loading, unloading, clearing, setting the scale, stepping, printing and exporting plus a few commands that query the state of the large D2D pane.

Extensions

The extension mechanism provides a way for external programs like warnGen or baselines to render very simple vector graphics objects inside a display pane's single colored overlay.  The set of supported objects is limited to points, lines, polylines, and polygons and each of these can be annotated with a text label.    Overlays dedicated to extensions have a unique advantage over other overlays in that the overlay contents can be directly manipulated by the user.  She can interactively move all four kinds of objects and also add and remove vertices to the polyline and polygon objects.  The extension program reacts to user operations on these objects via callbacks.

Extensions represent overlays the same way that the IGC does: a sequence of depictable objects displaying items associated with a particular time.  One important difference though:  extensions can't specify their own inventory; they are hard-wired to always use the time sequence of the first product loaded in the display pane.  If there isn't a product loaded, the IGC gives the extension an artificial time sequence to use, which is based on the current time.  Extension overlays can be static and will be managed much like a map background.  Static overlays have only a single depictable object that has no time associated with it.  In this case, the graphics of that sole depictable will be overlayed in each active frame.

Extensions are not trivial to write; the extension author should have a working knowledge of the C++ concepts of inheritance and polymorphism.  An extension writer develops code that defines the functionality of the extension and interacts with the display pane through the classes in the extension foundation and the interactive depictables.  Here's more detail about the three major components of every extension program:

• Extension Foundation:  An AWIPS collection of classes that form the infrastructure of the extension.  Here's an overview of what's here:
  
• The most important of these classes is Extension.  Extension writers almost always create a class that inherits from this one.  If they fail to do so, the class has a default implementation, but it is not very interesting or useful.  The callbacks are implemented by redefining the virtual functions in this class. The most important callback of this class, handleIntDepictSeqChanged(), is called when the extension first starts up or whenever the IGC's time sequence changes due to an auto-update or an increases/decrease of the number of active frames.  The extension foundation will receive from the IGC the new time sequence of the overlay.  The foundation software will compare the new sequence with the existing list of depictables and delete or add empty depictables accordingly. This callback will pass in the list of new interactive depictable objects that have just been created and also a list of depictables that are being destroyed.  The extension writer now has a chance to add graphic objects to the new depictables or save graphic objects from the depictables that are about to be destroyed.  The extension class has many other callbacks for the extension writer to define as well, such as responding to the edit of a graphic object, handling when the active frame has changed from a step operation and handling when the user activates or deactivates the interactivity of the extension's overlay.
• Foundation also includes classes that allow the extension writer to query and set some characteristics of the display pane.  These classes are highly controversial, but fortunately have not been used all that much.  An extension writer can learn about the other product overlays that are being displayed in the same pane as the extension and perform operations on them like toggling their visibility.  Also an extension writer can learn about the zoom factor and center point of the display and perform zooming and roaming on the display pane.
  
• Foundation also implements the IPC between the extension foundation and the ExtMgr and interactive depictable components of the IGC_Process.
• Foundation also has elaborate machinery to start an extension in a generic way; this is an attempt to implement the factory design pattern.
  
• Interactive Depictables:  A sequence of depictable objects that serve the same purpose as the depictable objects in the IGC: transform items of a particular time into a format that can be sent to the graphics hardware for display.   Static extensions have a sequence of only one depictable that isn't associated with any time.  Although extension and IGC depictables have the same purpose, their implementation and design couldn't be more different.  IGC depictables access their own data while extension depictables deal only with graphics objects that are created and specified by the extension writer.  These conceptual graphics objects (points, lines, polylines and polygons) each have a C++ class that defines them.  The extension writer is responsible for filling these graphics objects with coordinates (the coordinate projection currently in use by the IGC can be obtained through extension foundation objects), and then adding or removing these objects to the depictable object associated with the desired time.  Another important characteristic of interactive depictables is that each object in the extension has a partner object in the IGC that is connected by IPC.  The actual rendering and interactive editing of the graphic objects are implemented in the IGC's associated interactive depictable.
  
• Extension Specific Code:  Code written by the extension writer that defines the functionality of the extension and how it interacts with the display pane it is assigned to.  The extension writer usually designs at least one C++ class that handles the callbacks generated from the IGC which describe some action that was performed on the extension's overlay.   The developer displays and alters graphics by creating or editing graphics objects and adding or deleting these graphics objects to the depictable associated with the desired time.  Beyond the necessary C++ interfaces, extension specific code can contain code written in any language that implements other aspects of the extension such as the management of a GUI.
  

Proposed Architecture

The following diagram and sections describe how we will morph the current architecture into the ALPS display architecture.   Like its AWIPS counterpart, ALPS display software will be organized into the various building blocks and conduits that implement the same high level requirements guiding AWIPS.  In the diagram, the building blocks and conduits that are depicted with solid lines are existing AWIPS components that we may have to tweak in some instances.  The objects depicted with dashed lines are brand new building blocks and conduits to be introduced with ALPS.

Proposed ALPS Display Architecture

Data Access

Data access will be considerably different under ALPS in order to support a distributed data mechanism where the display executables will be able to transparently access data from a local device or a device at another site across a wide area network.  As in AWIPS, the data access requirements will be implemented by the ingest software and development team.  As with the display software, the details of the ALPS ingest software are still being worked out at the time of this document's writing.  At this point, the probable interface will be through a new executable called the InventoryServer that will provide data access, inventory and new data notification services which will replace the AWIPS notificationServer.  There probably will still be a notificationServer executable but it will serve a different purpose in the new ingest architecture. 

Display Access

Today, there are newer open source packages implementing display access and widget sets that have distinct advantages over Tcl/Tk and X11.  For example, Python uses the Tk widget set but is wrapped around an object oriented scripting language.  OpenGL like X11 supports two dimensional graphics rendering and input device management but OpenGL also accesses the power of the 3D capabilities of /***************************graphics hardware which sometimes can improve the performance of 2D rendering as well.

However, if new packages were to be integrated, a significant portion of data visualization, selection and interaction code would have to be rewritten.  Since one of the aforementioned goals is to minimize the disposal of existing code, display access in ALPS will continue to be handled by the X11 and Tcl/Tk packages.

Data Selection and Interaction

Like AWIPS, the ALPS architecture relies on the fxaWish executable to provide the user with the tools necessary to select and interact with the data being visualized.  Most of the executable's existing structure and code will be carried over into ALPS.  However, a few components will be added to support automated plugin integration.  

Application and extension writers have to make 2-4 table entries in order to integrate their external executable.  Our hope is to eliminate table entries completely, although this may be an ambitious goal for the first prototype.  What we have in mind though is that the plugin author would just have to drop the executable in a plugins directory.  fxaWish would scan that directory and start each plugin and use its introspective capabilities to obtain enough information about it to place it in a menu.  Once the plugin has identified itself and its attributes, it can be terminated.  Probably for now, there would just be an entry in a simple "plugins" menu accessible through the D2D menu bar.  Perhaps in the future, the plugin writer will have a way of specifying a nested menu location when registering the plugin.  Here are the new components that we propose to add to fxaWish:

• Plugin Host Base:  A reusable library that is required for executables that plan on hosting plugins.  It contains the code to start plugins and to listen for and receive plugin messages as well as sending messages to plugins.  Client code can register callbacks that will be invoked when messages are received from a particular or any plugin.
• Plugin Menu Mgr:  A new collection of module(s) that may be written in either C or Tcl.  For each plugin contained in the "plugins" directory, the PluginHostBase library will be asked to start the plugin and call one of this component's functions when the plugin registers with its attributes.  These attributes will be used to make a product button which will start the plugin when activated and the button is inserted into some appropriate menu, perhaps specified by the attributes.  Probably, this component will call some existing code in the D2D Tcl/Tk script collection that manages product buttons and menus.  Once the plugin button has been constructed, the PluginHostBase library will stop the plugin.
  

Data Visualization

Replace Extension with Plugin Framework

Improve Overlay Capability

Relocate Depictables

• It is likely that depictables with the same time and perhaps even the same coordinate domain will be active at the same time on a host in different IGC panes.  For example, the 0.5 reflectivity for the home radar usually shows up quite often in different panes.  Now each IGC associated with those panes consume a considerable amount of processing and memory to access the data and perform the coordinate mapping from polar to Cartesian coordinates.  Ideally, the server could do it once for multiple IGC clients.  Even if depictables don't share the same projection and domain but do share the same time, there probably are some data that can be shared.  A server process could have common data structures shared by all depictables to facilitate sharing and communication among depictables.
• IGC executables will become considerably more lean and reliable since the majority of the current code is either depictables or support libraries that depictables use to access data.  Another advantage of having one depictable server is that it will be noticed right away if it crashes and can be easily restarted without seriously affecting the user.  That would be a big improvement over AWIPS when depictable code sometimes causes an IGC to crash which leads to a temporary loss of all products being displayed in the pane (although easily restored with a bundle).
• The well defined interfaces and separation between IGC components and the depictables that currently exist in AWIPS facilitates migration to a client/server model.
• Perhaps some day, plugins as well as IGCs could be clients of a depictable server.
  

• DepictServer:  Component that receives requests from clients for depictable rendering services and will create depictable objects if necessary.  Depictable objects will be deleted only when there are no clients displaying the rendering of that depictable. 
  
• Depictables:  Hopefully, the depictable library can be relocated from the IGC into a server with few changes.  Realistically though, if real sharing between depictables and thus significant performance is to be realized, some depictable code will be modified. 
  
• PainterProxy:  Classes that implement the same painter interface currently used by depictables but rendering commands are sent via IPC to the Painter component of the client that originally made the rendering request.

External Functionality

The architecture supporting this requirement will undergo a complete overhaul.  A pretty thorough introduction of how and why plugins will replace applications and extensions has already been presented in the extensibility goal section. 

The plugin mechanism will provide a way for external programs like warnGen or a collaboration tool to render complicated vector graphics or images inside a display pane's overlay.  The characteristics of this overlay will be controlled by the plugin.  For example, the plugin will decide whether it needs a multi-colored overlay or can get by with a more efficient single colored overlay.  The plugin will also specify the time attributes of the overlay such as whether the controlling time sequence will come from the first product loaded (as warnGen now works) or the sequence will come from a plugin-specified inventory that is time matched with the first product loaded.  A third possibility is that the plugin opts for a static overlay, which behaves like a map background.  In this case, the plugin will not have to be concerned about managing time.

The plugin mechanism will also provide a way for external programs like the volume browser to extend data selection and interaction or to export displayed data into a standard graphics meta-file format.  The "Scalable Vector Graphics" (SVG) format is currently being considered. 

Both of these sets of plugin functionality will be packaged in two separate reusable libraries; a plugin can reduce its executable size by choosing to link with only the plugin libraries that deliver the desired functionality.  However, all plugins will need to link in the PluginBase library in order to communicate and register with the core system.  If a plugin links in all three of these libraries, the plugin will contain all the functionality that AWIPS applications and extensions do, but in one executable.  There is already some functionality in AWIPS that could take advantage of this: the capability of a user specifying a home location by either dragging a point on the display or by selecting a city from a dialog box.  Currently, this is split into the home extension and the putCursor application but using the ALPS paradigm, the two executables  could be merged into the homeCursor plugin.

For the initial prototype, a plugin will have at most the following four components but may contain fewer.  However, additional libraries that build upon the existing libraries may be developed later.  For example, we may later provide a library of sophisticated graphics objects that are implemented by using the primitives of the PluginDrawAPI.  The reusable libraries will initially be developed in C but we plan to offer API wrappers in other supported languages. 

• PluginBase:  Required reusable library containing the plugin's backbone.  This library serves two main purposes:
1. Implements TCP/IP socket IPC between the plugin and the host system.
2. Provides an interface for plugin writers to register their plugin's attributes with the host system.

• PluginDrawAPI:  Optional reusable library that provides a plugin writer with a way to display single- or multi-colored vector graphics and images in a D2D pane overlay dedicated to the plugin.  This will be a very rich API that includes and goes beyond rendering lines, text and images.  Here are some of the features that we are considering or already committed to:
• Support rendering of vectors (linked and unlinked), points, arcs, text, symbols and images
  
• Complete rendering attribute control such as line width and style, color, font, etc...  The interface for specifying attributes will probably be similar to the graphics context concept used in Xlib.
• A draw callback that is invoked when the host display system needs to re-render a particular frame that contains the plugin's rendering.  The callback will pass back the time that corresponds to the plugin's rendering.  The IGC has the capability of preparing frames in the background, so this callback could be called well before the actual frame display.
  
• Coordinate conversion and projection tools.
• Return events associated with the mouse and keyboard when the user activates the plugin's overlay as interactive.
• Set/get the plugin's overlay time sequence or bind it to the time sequence of the first project loaded in the display pane.  If setting the time sequence, and a product is already loaded, a new time sequence will be returned which is the result of the plugin's inventory being time-matched with the first product loaded.
• PluginDataAPI:  Optional reusable library that provides a plugin writer with many of the same capabilities for managing the contents of a display pane that D2D has.  This API will start with the commands in the current AWIPS application interface such as loading, exporting, clearing, setting the scale, stepping and printing  and add to the collection to make a complete and consistent interface.  Many of these commands will be sent directly to the appropriate IGC or fxaWish executable depending on the command.
  
• Plugin-Specific Code:  Code written by the plugin writer defining the functionality that the plugin provides.  At the very least, the plugin writer will have to make a call to the PluginBase API in order to register the plugin with the host system.  Depending on the purpose of the plugin, the author will use either the draw or data APIs or both to interact with the ALPS core system.  The ALPS core system will also call plugin-specific code if callbacks are registered and certain events are triggered.
  

Implementation Strategy

We will probably retrofit this ALPS architecture on top of the AWIPS architecture using the same spiral incremental software development model we used to develop AWIPS.  We will start out by breaking the entire task into achievable milestones.  Even though the milestones will be incremental, there will probably be parallel development in between milestones.  Here are some of the larger milestones we can identify now.  As we proceed, we will refine these into smaller checkpoints.

Phase 1:  Create Plugin Infrastructure

We identified the conversion of applications and extensions to plugins as the biggest impediment towards the successful transition to this new architecture.  Thus, we will start by building the plugin infrastructure which consists of the Plugin Base and Plugin Host Base reusable libraries.  Once these are built, we can integrate the Plugin Host into the IGC and fxaWish by building the anchor software components in these processes.  Plugins are managed by the PluginMgr in IGC and by the PluginMenuMgr in fxaWish.

Once these support pieces are in place, plugins won't do anything useful until the PluginDataAPI and PluginDrawAPI reusable libraries are developed, which is the next step.  The initial cut of the header file plugin developers will use to draw onto an IGC overlay has already been written.  So we will start by refining the programmer's interface to the PluginDrawAPI library.  In parallel, we can develop the back end of this library as well as the hook into the IGC, the PluginDepictable.   Plugins, unlike extensions, support full color rendering and this will be implemented fully inside the PluginDrawAPI.  However, for this phase, the PluginDepictable will ignore the color settings and display inside a single-colored overlay. Full color plugins will be available by the end of the next phase.  Once the API for drawing is finished, we'll start work on the PluginDataAPI library and its integration into the IGC via the PluginMgr.

If the IGC integration takes longer than the plugin infrastructure development, a stand-alone plugin host program can be developed for running a plugin inside a simple host environment.  Such a program may prove very useful for plugin developers that don't have access to an entire AWIPS/ALPS system.   To show proof of concept, we will write some plugins that demonstrate some frequently used capabilities of both the data and draw interfaces. 

Phase 2:  Plugin Development and Migration

Phase 3:  Integrate Distributed Data Access

This document is maintained by Gerry Murray. Last modified: 11/02/2004