



	   ################################################
	   #                                              #
	   # ##   ## ###### ####### ##    ## ## ##     ## #
	   # ##   ## ##  ## ##      ###   ## ##  ##   ##  #
	   # ##   ## ##     ##      ####  ## ##   ## ##   #
	   # ##   ## ###### ######  ## ## ## ##    ###    #
	   # ##   ##     ## ##      ##  #### ##   ## ##   #
	   # ##   ## ##  ## ##      ##   ### ##  ##   ##  #
	   # ####### ###### ####### ##    ## ## ##     ## #
	   #                                              #
	   ################################################






 
 
 
	 The following paper was originally presented at the

		     Third Annual Tcl/Tk Workshop
		 Toronto, Ontario, Canada, July 1995

	   sponsored by Unisys, Inc. and USENIX Association



	    It was published by USENIX Association in the
		  1995 Tcl/Tk Workshop Proceedings.
 
 
 
 
        For more information about USENIX Association contact:
 
                   1. Phone:    510 528-8649
                   2. FAX:      510 548-5738
                   3. Email:    office@usenix.org
                   4. WWW URL:  http://www.usenix.org
 
 
 
 
 
^L
     Prototyping NBC's GEnesis Broadcast Automation System Using Tcl/Tk

Brion D. Sarachan				
GE R & D Center      		      		
P.O. Box 8, KW C273				
Schenectady, NY 12301				
Phone: (518)  387-6553				
Email: sarachanbd@crd.ge.com		

Alexandra J. Schmidt
GE R & D Center
P.O. Box 8, KW D218
Schenectady, NY 12301
Phone:  (518) 387-7271
Email: aschmidt@crd.ge.com

Steven A. Zahner
National Broadcasting Company, Inc.
Broadcast and Network Operations
30 Rockefeller Plaza
New York, NY 10112
Phone: (212) 664-7109
Email: zahner@oandtsvt.nbc.com

ABSTRACT

As part of the re-architecture of their television broadcast transmission
facility, NBC is using Tcl/Tk in developing a prototype system, known as
GEnesis, for monitoring and editing on-air television broadcast schedules.
This paper discusses application of Tcl/Tk and its extensions to rapidly
prototype a highly-interactive GEnesis user interface that leverages the
power and flexibility of the Tk widget set.  In particular, canvases are
used to implement custom graphics, while tags and the binding mechanism
enable a high degree of interactivity.  The ability of Tcl/Tk to work
seamlessly with other, heterogeneous software components enables the GEnesis
system to combine its custom Tcl/Tk user interface with a Sybase database
and C-based device controllers.  We address a number of implementation
issues including the handling of display updates and managing the Tcl data
space.

KEYWORDS: Tk-based user interfaces, Tcl-based database interaction,
interprocess communication, broadcasting operations.

INTRODUCTION

NBC's GEnesis project comprises a general re-architecture of NBC's
end-to-end television broadcast process.  A particularly important part of
GEnesis concerns the monitoring and control of program streams--the
continuous sequence of television program and commercial events which are
combined in varying ways according to local affiliate station needs, then
routed by satellite to the correct groups of stations.  NBC is presently
prototyping GEnesis in conjunction with the General Electric Research and
Development Center.  This paper focuses on the use of Tcl and Tk in
developing the prototype's architecture and display.

Several requirements shaped the design and implementation approach.
Broadcast schedules are extremely complex and are, in fact,
multidimensional; schedules differ for different geographic regions;
schedules are modified over time (sometimes up to the last moments before
broadcast); alternate contingency schedules are routinely created to allow
coverage for world news events.  GEnesis poses the challenge of graphically
representing and tracking this complexity of schedule information.  Although
schedules are stored in a database prior to airing, the frequent need for
close-to-air-time modifications mandates an intuitive user interface that
provides quick access to and understanding of the extremely complex schedule
information and also allows easy schedule edits that minimize the need for
extensive typing--a common source of potentially-costly schedule errors.
Finally, the entire prototype architecture needs to be extremely reliable.

This paper presents an overview of the factors influencing NBC's decision to
use Tcl/Tk and related extensions in prototyping GEnesis, as well as issues
involved in the ongoing design of both the user interface and the system
architecture.  In addition, we discuss our approach to addressing a number
of design tradeoffs we have encountered over the course of the project to
date.

PROJECT MOTIVATION AND SELECTION OF TCL/TK

GEnesis requires quick operator interaction in response to real-time,
mission-critical changes within a complex system.  As a result, NBC's major
goal was to incorporate operator ideas into the user interface and system
design.  In doing this, two related issues needed to be addressed.  First,
many different systems were being merged into one unified system and very
few operators were able to envision how the new system would work.  Second,
the systems to be replaced were heavily text based, originally running on
VT-100 terminals.  As the operators had limited experience with other types
of user interfaces, the prototype needed to allow rapid modification over
the course of its development, based on user feedback.

The prototype system objectives were twofold: demonstration of possible
operating scenarios and screen layouts to the operators, and development of
a user interface which would simplify data management as NBC transitioned to
more complex digital video.

Not having the personnel or the expertise to develop a working prototype in
the time available, NBC turned to GE Research & Development for assistance.
After visiting GE and reviewing various software development tools,
environments and interpreters, NBC decided to investigate the possibility of
using Tcl/Tk as the development toolkit.  Impressed with the speed with
which NBC engineers were able to begin building applications, NBC decided
that Tcl/Tk presented the best approach to take in developing the prototype.

The Tcl and Tk toolkit provided all the functionality NBC was looking for in
a development tool: speedy development time, the ability to change software
quickly to meet new operator requirements, and the ability to relate data
from many different sources both graphically and in a text-based fashion.
As one component in a much larger system, it also offered an environment
well-suited to seamless integration.  As compared to other X-based
programming tools, Tcl/Tk made it very easy to access the existing Sybase
database using sybtcl, and TCP/IP communications via Tcl-DP.  Tcl/Tk offered
a best-of-both-worlds approach, leveraging commercial database and
semi-commercial control software in conjunction with a custom user
interface.  These extensions allowed us to remove the mission-critical
software from the user interface and create an architecture that provided
the reliability required not only for the prototype, but for the final
production system.

In the past, because NBC's legacy systems were developed with a variety of
hardware, tools, and programming languages, software changes or bug fixes
have frequently been costly or required out-of-house expertise.  Since then,
an increasingly complex broadcast control system has evolved, putting
greater demands on the broadcast operators.  The only way to bridge the gap
between increased operator workload and increased system flexibility is to
provide better, more intuitive, and more easily customizable user
interfaces.  The ability for NBC's developers to inherit software from
outside contractors such as GE Research & Development, then support and
maintain it on a variety of hardware platforms, makes Tcl/Tk very
attractive.

DISPLAY PROTOTYPING

In addition to providing a venue for rapidly trying out new ideas for
broadcast schedule displays, the GEnesis user interface needs to clearly
show different timing relationships within the schedule.  We have found that
novel types of screen displays that have been brainstormed on white boards
during meetings or simply sketched on paper can generally be prototyped in
Tcl/Tk in a matter of hours.

Figure 1 shows the main home screen currently provided by the GEnesis
prototype.  Broadcast operators emphasized the concept of a home screen,
since they need to be able to quickly jump to a known context during
emergency situations.  This display is based on early paper sketches for the
GEnesis user interface and conveys a clear, intuitive view of an integrated
broadcast schedule for a main group of affiliate stations together with
several regional groups that differ from the main group in some program
content--typically, different commercials.  The integrated schedule, sorted
chronologically, is displayed in the text widget on the left.  The smaller
text widgets on the right show the same aggregate schedule, but here
separated by regional group.

Initial Prototyping

This basic display was quite easy to create in Tcl/Tk, and a first mockup
was put together in 20 minutes.  This initial mockup even included a live
clock that was easily implemented by periodically calling "exec date" and
displaying the results in a label widget.  (This clock was the early
precursor to the more sophisticated timing mechanisms added later.)  It then
became a weekend project to build a mechanism that fills the integrated and
regional schedule displays with sample data, and at this point it became
clear that Tk's binding mechanism and text tags could be leveraged to good
advantage.

Figure 1.  GEnesis prototype main screen

The integrated and regional displays are implemented as text widgets that
display broadcast information including program title, start time, source
video device, regional group, status, etc.  A color coded text tag was added
to each text field, and <Enter> and <Leave> bindings were created for each
named tag.  The result is that, as the cursor is moved within a schedule
display, all like items (i.e. all programs having the same title or using
the same video device) highlight together when any are touched by the
cursor.  This mechanism was further extended by creating <Button-1> bindings
that leave the selected item highlighted when the left mouse button is
clicked.  Generally, the tag bindings are creating as shown in figure 2.

Figure 2.  Schedule display tag bindings

The selection in the pseudo-code of figure 2 differs from the usual Tk
selection, which refers to an individual user interface item, only.  The
selection here refers instead to an item in the broadcast schedule which may
be broadcast material, a video disk machine, etc., and which may appear in
multiple places in the user interface simultaneously.  The current selection
is indicated in the main screen. (See figure 1.)

A simple loop applies the interactive highlighting to all
currently-displayed text widgets:

foreach win $GEnesis_displayed_text_widgets{
    foreach tg [$win tag names] {
        if {[string match $tagname $tg]} {
	$win tag configure $tg 
		-background $color
        }
    }
}

The color-coded analog clock face in the upper left of the main screen also
resulted from brainstorming intuitive, novel ways to display time.  The
color-coded wedges within the clock face correspond to particular,
pre-defined segments of the broadcast schedule.  This clock face was easily
prototyped in a few hours using a canvas widget with filled arcs, and a
little simple trigonometry to derive the angles of each arc from times
within the broadcast schedule.  Also, tags were assigned to each clock wedge
and associated with the tags in the schedule displays described above.  This
provides a mechanism by which clicking in a clock wedge causes the
corresponding portion of the broadcast schedule to highlight in each of the
schedule displays.

The toolbar provides various commands for requesting more information about
the current selection.  For example, if the current selection is an
affiliate station, then the Schedule toolbar button will create a new window
containing the schedule of material played for that affiliate.  (See figure
3.)  Note that the affiliate schedule popup contains buttons for e-mailing
or faxing the schedule directly to the affiliate, thus leveraging Tcl's
ability to seamlessly call upon other software services to easily give
additional capabilities to the user.

Figure 3.  Affiliate station schedule accessed using current selection and
toolbar

As the previous discussion suggests, the GEnesis displays use quite a few
tags for interactive highlighting and selection.  This leads to some issues
in tag management.  First, we use a naming convention in which each tag's
name indicates: its corresponding item in the broadcast schedule (i.e. which
device or material), its corresponding event in the broadcast schedule, and
whether the tag has interactive bindings, or is used for highlighting, only.

For example, a tag name may be something like:
	my-favorite-sitcom_button_event_33

Since the Tcl "string match" function accepts wildcards, it is easy to then
highlight, for example, all tags matching: my-favorite-sitcom_button_*

Another issue in tag management is that of garbage collecting old tags as
the display contents change over time.  When portions of text are deleted
from a Tk text widget, Tk does a very good job of also deleting the
corresponding text ranges from the widget's tags.  However, the tags
themselves remain defined, even after they are no longer associated with any
text in the display.  (This is probably the most appropriate default
behavior for tag deletion, since in some applications it may not be
appropriate to delete text tags automatically.)  However, in GEnesis, we
would like "expired" text tags to disappear.  Our current approach is to
recreate the contents of each text widget from scratch periodically.  The
alternative would be a rather elaborate scheme tracking the usage of each of
many text tags.

Timing Mechanism

After prototyping some initial GEnesis displays as described above, the next
step was to add a timing mechanism to the user interface to simulate the
execution of the broadcast schedule.  For example, it made sense to remove
each broadcast event from the schedule displays after execution of that
event was complete.

Rather than implementing a specialized timing mechanism that would work only
for certain displays, a very general and extensible timing mechanism has
been implemented, and subsequently leveraged for additional types of
animated displays described below.  Generally, the broadcast schedule is
organized as a list of events, where each event has a duration and either a
specific start time or conditions under which the event begins.  A general
timing loop was implemented that steps through the list of broadcast events
and recognizes when events are beginning and ending.  This timing loop then
calls several procedure stubs at the appropriate times: at each clock tick
as well as at the beginning and end of each event period.  Code that
animates each type of display is then inserted into these procedure stubs as
appropriate.

For example, the integrated and regional schedule displays were animated
using simple procedures that remove events from the display after they are
completed.  The result is that these schedules automatically scroll with
time such that the current event is always on top.

This timing mechanism also made it simple to add the on-air and next event
displays to the main screen.  (See figure 1.)  These displays are crucial so
that the broadcast operator always has the on-air information immediately
available.  Also, the countdown timers were easily added by simply
subtracting the current time from the next event times and displaying the
result in label widgets using the "textvariable" option.

The general timing mechanism was extended to include a flashing mechanism
that allows an arbitrary periodic event to occur for a specified amount of
time before each event transition.  In the current prototype, this mechanism
is used to flash next events in yellow (in each schedule where they appear)
for 5 seconds before they go on-air.

Early prototypes of the GEnesis timing mechanism continued to use the call
to "exec date" mentioned above.  Recently, this has been replaced with a
C-based custom timer module for a more smoothly-running clock.

Simultaneous broadcast events are not always synchronized.  Therefore, the
timing mechanism must allow multiple events to be initiated, where each has
its own separate duration and countdown.  (See again figure 1.)  Also,
whereas early GEnesis prototypes supported only broadcast events having
specific, scheduled start times, in practice, many broadcast events are
linked by dependencies on one another and initiated manually by the
broadcast operator.  The user interface timing mechanism now supports this
additional flexibility.

Animated Displays

The GEnesis user interface timing mechanism enabled the creation of several
other time-driven custom displays.  Figure 4 shows a sample map of affiliate
stations and their current connections to four satellite transponders.

Figure 4.  GEnesis Satellite Display

This display is animated with time; the satellite connections change as the
schedule executes, as does the label indicating the program being
transmitted by each satellite.  Also, the program titles and connecting
lines are color coded to easily differentiate them visually.  The resulting
display shows the current satellite connections to affiliate stations.
Initial user reaction to this display suggests that it is extremely
intuitive and provides a useful graphical supplement to the schedule
information text shown in the main screen.

The animated satellite map display was implemented in Tk using the GEnesis
timing mechanism described above, along with a Tk canvas containing bitmaps
(for the map and satellites), text (for the affiliates and program titles),
and connecting lines.  The data associated with the display was organized as
described in the "Object Mechanisms" section below.

Yet another custom display shows satellite transponder allocation as a
function of time. (See figure 5.)  Again, this display is animated using the
general timing mechanism described above.  The time indicator moves
horizontally across the screen, and transponders currently in use change
color such that the colors match those used in the satellite/station map
shown in figure 4.

These timelines are implemented with a canvas containing text, lines, and
rectangles, animated in time.  The duration of the event determines the
width of each rectangle, which is tagged with the transponder name and the
event start time.  When the timeline updates at the end of its period, the
tags are updated as well.

Figure 5.  Satellite Resource Display

Object Mechanisms in Tcl

Complex data structures and operations are conducive to an object-oriented
approach.  Although Tcl does not have built-in support for an object system,
Tcl is so flexible that it is easy to simulate object-like mechanisms in
Tcl.  This has been done where appropriate in the GEnesis prototype using
associative arrays for object-like data and using the Tcl interpreter as a
means of generating procedure names and obtaining polymorphic object-like
methods.

The general approach is to use associative arrays with a fixed naming
convention for the indices, such that each index of the array has the form
object-name%attribute-name.

For example, both the satellite map and transponder timeline displays shown
above have fairly complex sets of data associated with them.  For a given
widget named $w, we define an associative array called ${w}_data.  The array
indices follow the convention described above, where the objects are things
relevant to the type of display, such as satellite transponders or affiliate
television stations.  Attributes in these cases include transponder or
affiliate name, and x,y coordinates in the Tk canvas.  (See again figure 4.)

A benefit of this approach is that it is extremely easy to clean up object
data when a widget is destroyed.  There is simply a binding to the widget's
<Destroy> event that calls unset ${w}_data and this destroys all the object
data at once.

It is also desirable within the GEnesis user interface to have polymorphic
methods that update each display with time, regardless of the type of the
display.  The convention used is that each displayed widget has a name that
ends in widget-type%widget-instance.  For example, the text widget that
displays the schedule for the first regional group has the widget name:
.regional_schedule%regional_1

A loop that updates all time-dependent displays parses the name of each
displayed widget to determine its type and instance, and then calls:
GEnesis_redisplay_${widget-type} $w $widget-instance

Here $w evaluates to the actual Tk widget name, and $widget-instance is a
logical identifier for the widget, such as "regional_1" in the example
above.  Note that this sort of dynamic generation of procedure names is
possible because Tcl is interpreted rather than compiled.

The convention described here for structuring object data and methods has
been used throughout the GEnesis prototype.  We have found that this
approach enables us to write code that is almost self-documenting; the
structured array indices described above clearly identify the attributes of
each object.  This approach has also allowed us to prototype an
object-oriented design in Tcl.  Much of the logic for broadcast schedules
implemented in the GEnesis prototype could be readily ported to other
implementation languages, such as C++, while still retaining its current
design.

SYSTEM ARCHITECTURE

The preceding section provides an in-depth look at the user interface.  This
section focuses primarily on the data server, the controller, and
interprocess communication in both C and Tcl.

The overall system architecture for the prototype is partitioned into
several distinct elements, each of which is a separate process and can be
launched separately from a system startup display.  Each element needs to
communicate with the others but be capable of a decoupled restart in case of
a partial system failure.  Furthermore, the system needs to handle internal
checking to confirm operational status of all connected devices and switch
to the appropriate backup options if necessary.  Figure 6 indicates the
system architecture elements.  Tcl's ability to integrate easily with
disparate software system components in a hybrid architecture allows the
GEnesis Tcl/Tk user interface to work seamlessly with other third party and
custom software.



Figure 6.  GEnesis prototype system architecture elements



Data Server Prototype in Tcl

Several factors motivated the decision to implement a data server interface
between the user interface and the Sybase database.  The server handles data
requests from the rest of the system, and distributes changes made at the
schedule database level to the controller and the user interface.  It
provides a flexible layer designed to minimize the modifications to the rest
of GEnesis with the use of a different commercial database system.  Also,
since GEnesis must be highly reliable in a real-time environment, the data
server monitors the status of the database and switches to an alternate
database if necessary.  The server process can handle lengthy database
transactions asychronously from the user interface, so that the user
interface need not pause during these transactions.

We have used Tcl to rapidly prototype the data server, and intend to port
the data server to C once the data protocols and database schema are
well-defined.  We have used two Tcl extensions: Tcl-DP (for TCP/IP socket
management) and sybtcl (which accesses the Sybase server in a manner similar
to Sybase tools such as embedded SQL and Open Client).  Using these
extensions, we have found it to be extremely easy to prototype the data
server, due to the convenient APIs provided by Tcl-DP and sybtcl, and to the
extensive string manipulation functions inherent in Tcl.

Sybase queries generally return a table of data. Sybtcl provides an
interface to Sybase similar to that of Sybase Open Client.  Sybtcl and Open
Client both store query results in their own data structures and allow these
results to be accessed one row at a time.  However, sybtcl worked
particularly well with the format of the GEnesis broadcast events and
SybaseUs string-based query structure.  Within Tcl, GEnesis events are
stored as string lists; sybtcl returns query results in the same format.
This greatly simplifies much of the GEnesis database interface code.  To
illustrate, the code below uses the information in a Sybase table called
GEnesis_db_event to update a global array variable called GEnesis_events The
code handles particular request criteria by specifying the conditions as a
separate string variable called $criteria.

global GEnesis_events	
sybsql $sybase_handle  select event_id,  <other fields> 
	from GEnesis_db_event where $criteria
sybnext $sybase_handle Rlappend event_list @0
foreach event $event_list {
    set GEnesis_events([lindex $event 0]) 
        [lreplace $event 0 0]
}

The sybnext call provides the flexibility of an optional third argument
which can be used to append all columns of the returned query to an
arbitrary internal variable.  We then update the global array, indexing the
array elements by the event identification number.

In actually implementing the above example, we wrote our own wrapper for the
sybtcl sybsql procedure, incorporating Tcl's catch error-trapping facility
and bringing up a Tk error screen explaining the cause of the error.  This
type of added functionality is valuable to the prototype because GEnesis
needs to flag not only internal scheduling errors at the database level, but
also database querying errors.  The internal event storage in Tcl provides
an extra measure of security in the event of a total database or server
failure.

Once the query results are obtained, they are then formatted within a
GEnesis-specific protocol and directed to the requesting process--the user
interface or the controller--via Tcl-DP socket links.

Device Controller Implementation  in C, Simulation with Tk

The device controller poses unique challenges of the three major system
components because it communicates with an arbitrary number of drivers for
different devices (for example, different types of video players).  While
the types of actions to be taken fall into a manageable number of categories
on the controller side, their implementation on the device driver side is
primarily device-specific.

We chose to address this issue by retaining a simple, string-based protocol
for communication, while implementing the controller and drivers in C for
reliability and customizability.  This approach is particularly natural for
the device drivers, which are designed to be most easily controlled via C.
The string-based protocol contains both delimiting characters and byte-count
information to facilitate its use in C as well as in Tcl.  All communication
is done with Berkeley sockets, using a client-server model in which each
device listens for connections from the controller and then subsequently
executes its specific list of events.  Similarly, the user interface acts as
a server for controller connections.  In this case, the Tcl/Tk user
interface uses Tcl-DP; it communicates seamlessly with the C-coded
controller.

Many commercial video devices can be controlled using a socket interface,
typically under a Windows NT operating system.  For preliminary simulation
and testing, we simulate the socket protocol supported by a typical video
device.  We are using Tcl/Tk for this device simulation, so that the
simulated device status can be graphically displayed, and so that simulated
error conditions can be interactively created.  These initial device
simulators have been implemented under UNIX-based workstations, but Tcl/Tk's
portability offers promise for running similar experiments on the PC
interfaces packaged with many of the devices being used in GEnesis.

In negotiating the tradeoffs between using Tcl-DP and directly coding the
sockets on the controller and device side, we found that the purpose of the
particular system component largely dictated the approach.  The added
flexibility of C coding (for example, in handling blocking and
interruptions) was necessary for real-time execution on the controller side
and less crucial on the user interface side.  However, the coding speed
advantage of Tcl-DP has proved very valuable, and an incentive to use it as
much as possible.

Communication Protocols

Tcl's native use of an easily-readable string datatype, and Sybase's
string-based data query results, led naturally to a string-based protocols
for data transfer between the three main system components.  By isolating
the device-specific parsing to the level between the controller and the
devices and handling it all in C, the protocols being used to communicate to
the controller can be made much more general.  This builds in a much easier
extensibility as different types of devices are added to the controller.

We have designed specific protocols for data server communication, regular
checking from the process monitor to make sure that all devices are alive
and on-line, local configuration and logging information, and control.  All
protocol messages use newline characters to delineate message lines, and
tabs to indicate separate fields within each line.

We have not yet encountered a need to represent non-printable
characters--for which Tcl has no representation--within protocol messages.
Should this be necessary, this functionality could be provided via C support
code.

KEY ISSUES

Speed and Display Updates

The GEnesis Tcl/Tk user interface is used primarily on a SPARCstation 20
with dual processors.  Although this hardware is very fast, the animated
nature of the GEnesis user interface creates some unusual user interface
performance issues.  The user interface provide real-time clocks and event
countdown timers.  It is important for these to run smoothly, since the
broadcast operators are accustomed to precise second-by-second timing, and
would find any delays or jumpiness in the clocks unnatural.

Initial implementations of the GEnesis user interface did in fact have
deficiencies in the smoothness of the clocks.  The situation was somewhat
improved by replacing the initial, crude time driver (explicit calls to
"exec date") with a custom, C-based timer handler.  This resulted in
smoothly running clocks during periods of time with no other display
updates.

Some slight clock pausing still occurs during instants of time when many of
the text and canvas widgets are being updated at the same time.  We suspect
that this delay is due in part to the queuing of X updates, and hence cannot
be greatly improved from the Tcl level.  We have improved performance
further by staggering the updates to individual widgets, and the clock
smoothness is now acceptable.

Structured Versus Unstructured Language

Tcl supports one basic datatype, the text string.  The GEnesis Tcl code
makes extensive use of the two primary data structures available: lists and
arrays.  Most primary data read in from external files or Sybase queries is
initially formatted as lists, but the majority of the global variables are
arrays indexed by either time or event identification number.  Because Tcl
does not explicitly support a constant declaration, variables whose values
are essentially static are also global.

As compared with other X-based user interface and application work we have
done using C-based toolkits, the key programmatical difference has been
Tcl's inability to provide user-defined datatypes, constants, and other
traditional C header information.  As a result, we have had the options of
either passing a large number of parameters to our procedures (particularly
those doing significant drawing), encapsulating the parameters into an array
structure and passing the arrays, or simply using the arrays as globals.  In
the majority of cases, we have created global arrays, even when the array
information is specific only to one particular display.  (Refer to "Object
Mechanisms in Tcl" for examples of this usage.)

The tradeoff has been one of rapid development time versus using
encapsulated data structures tailored to the application.  Tcl's speed
and flexibility have allowed us to build the prototype quickly using array
structures, largely because the GEnesis project did not mandate
application-specific structures from the beginning.  We will be following
the development and use of structured Tcl extensions such as {incr tcl} with
interest.  In addition, the associative array naming conventions we use
could eventually map to a C or C++ structure or class.

Global Variable Use

As discussed above, the GEnesis prototype makes fairly extensive use of
global variables to ease data accessibility while reducing extensive
parameter passing throughout the Tcl code modules.  Global variables fall
into several major categories: those associated with broadcast schedule
data, those associated with timer handling, those associated with the user
interface, and those associated with particular displays.

In managing the development code, we have kept separate version-tracked
documentation listing all global variables and their usage.  This has been
necessary to track the variables being used within a growing number of Tcl
modules, since Tcl does not provide a way to create a header applicable to
all procedures in a file.

Preliminary investigation has not indicated any speed decrease attributable
to global variable use.  However, this remains an issue that concerns us
long-term as the prototype continues to be extended.

CONCLUSION

In applying Tcl/Tk and its extensions to the GEnesis prototype, we have been
able to quickly design an integrated system which handles and displays
schedule dataflow and execution, allowing manual data editing and command
execution.  The Tcl/Tk toolkit has not only been an effective approach in
the GEnesis prototype development, but appears very promising as a tool for
the final long-term system implementation.  We have found several major
advantages to using Tcl/Tk: powerful widgets having unusual flexibility
(i.e. tags and binding mechanism), easy to rapidly prototype and modify the
user interface, seamless integration with disparate software components,
and portability to many platforms.

The ability for NBC to quickly and easily inherit and extend the GEnesis
prototype software initially developed in collaboration with the GE Research
& Development Center will be a major factor influencing the NBC decision to
continue production system development with Tcl/Tk.

Over the short-term, Tcl/Tk has provided an excellent environment for
rapidly prototyping many system components in the distributed GEnesis
architecture.  For the long-term, we expect that Tcl/Tk will provide the
GEnesis system with a powerful and flexible interactive user interface.

ACKNOWLEDGMENTS

The authors would like to thank Joe Amaral of NBC for the many hours he has
spent with us discussing display and architecture requirements, while
simultaneously maintaining a broad system view of how the GEnesis user
interface will interact with the rest of NBC's broadcast automation system.

Kevin Kenny of GE Research & Development deserves extra special thanks for
showing us an initial vision of what Tcl/Tk could bring to GEnesis,
contributing many valuable ideas to the GEnesis system architecture, and for
being available on a daily basis to share his expertise on seemingly every
aspect of Tcl/Tk.

Particularly in the case of an emerging engineering or software approach,
one is very much aware of the contributions of those on whose work one is
building.  In this light, we also wish to acknowledge and thank John
Ousterhout, Tom Poindexter (for sybtcl), and Brian Smith and Lawrence Rowe
(for Tcl-DP).


