Flash for Embedded Web Servers

Why Use Flash?

Using Flash content on an embedded web server may at first seem counter-intuitive. This is often because of the bad reputation Macromedia Flash has developed due to improper use by less desirable sites on the web. Put any personal opinions on Flash content to the side and look at what it can do for us.

1. Flash is a Client Technology: Flash isn't running on our embedded server. The web server just sources the content like it's conventional web content such as an image. Support for serving Flash files simply involves the configuration of a MIME type.
   
   
2. Flash Supports Vector Graphics: Flash provides support for vector graphics that are very small in size and can be scaled to any size without pixelization. Different sizes, colors, fills and orientations can all be generated from a single definition.
   
   
3. Flash Provides Client Code Execution: The Flash player allows for the embedded device to offload programming and execution to the client browser. Modern machines used to browse the web are almost certainly several times more powerful than the embedded systems serving the pages.
   
   
4. Flash is Commonly Available: Virtually every major platform and browser provides support for Flash with most installing the player by default.
   
   

A Practical Example

The following picture shows the panel display for the Champion Computer Technologies CCTx4 - a 4-port fiber-to-copper media converter. The CCTx4 includes a web interface for monitoring and configuration.

The panel display is provided on the web to give the user a quick reference to the performance of the device by simulating the front of the unit.

• Copper port status
• Fiber port status
• Port LED simulation
• Remote monitoring and terminal port status
• Chassis LED simulation

Raster Implementation

Lets take a look at building the interface using raster images. The first step is to build an image that is the basis of the device and then all of the components that we are going to lay on top of it to display the status. The implementation uses positioning support in CSS to drop the images representative of the status into the right locations on the display.

To implement this display using rasters, we will need the following image components:

• Background image - 12K
• RJ-45 ports (4 states - Idle, Failed, Error, OK) - 4K
• Fiber ports (4 states - Idle, Failed, Error, OK) - 4K
• LED (3 states - Off, On, Blinking) - 2K

Reducing these images using conventional tools and techniques ends up with files that add up to 22K bytes.

Implementing the page generation on the server is left as an exercise for the reader, but consider that the CGI code supported by the device will be responsible for calculating the position of each port image and selecting the correct image.

A more enterprising developer could implement the generation of the display in JavaScript running in the browser, but would still be saddled with the sizes of the images and a substantial block of client script.

Flash Implementation

Implementing the equivalent interface in Flash is straightforward and efficient. The Flash interface has always been designed to create small files by stressing the use of layers and libraries to implement displays. Unfortunately, it is not always used effectively.

The Flash version could utilize the existing graphics as embedded images do implement the display, but then we would miss out on the biggest optimization available. There is nothing in our display that cannot be generated using vector graphics. In fact, the original source for the front panel is vector-based in order to supply it to the screen printer.

Now we have simple representations of the ports that are independent of color and the tint is applied through the SWF display. The entire configuration for the display is generated as a string by the CGI code and supplied to the SWF on the object definition query string.

New states and representations are easy to add by simply updating the routine that generates the configuration string and the SWF movie with its new display properties. Our file size is reduced to 6KB.

The Payoff Continues

Now consider that the goal is to support all different models of the device with a single load of firmware. There are 2, 4, 12 and 24 port devices. The raster implementation can reuse the different image components, but scaling the background image the components to the different form factors will quickly create an ugly mess. Adding additional background images and different size components quickly balloons to over 75KB.

Flash comes to the rescue with its vector support. The different panel displays are easily generated with vector graphics all contained in the single SWF. Part of the configuration information passed to the SWF contains the number of ports that the device contains.

The larger devices require the display of a large number of ports in a small area of screen space. Flash allows for the mouse to cause a zoom-effect on a port as it is rolled over.

Our Flash components are also easy to animate, adding the nice finishing touches of animating the fans that are currently working and blinking the LED's that are flashing on the front panel without using more than a few bytes of ActionScript.

The Final Results

The initial materials provided for the project included an implementation of the display that utilized 175KB of images for inclusion on a device that is limited to 512KB of total program and data storage. A more informed and conservative raster implementation still uses a significant chunk of the available resources.

The Flash implementation provided a much smaller solution with improved functionality. In the hands of a capable Flash designer, the implementation time was measured in hours instead of days.