|Contract Client:||Graham Gash|
This project aims at developing a system to allow programs to be connected as a data-flow, with the output of one program driving the input of the next. This way complex programs can be constructed from a relatively simple set of primitive programs. Such a set of primitive programs is the /usr/Image image processing applications to blur an image, compute its Fourier transform, etc. An example data-flow is shown on the right. An input image is convolved with a kernel image. The result image and the input are displayed using the xdisp program. The system will have a user interface to create, edit and run such data-flow descriptions. It will not be limited to programs from /usr/Image and should work with any set of programs, provided their inputs and outputs can be described to the system.
The project group, hereafter referred to as the contractor,
agrees to develop a software system satisfying all the requirements mentioned
below under the heading "Primary Requirements" for Graham Gash, hereafter
referred to as the client. A user manual and online documentation will
also be provided along with the software.
The contractor also agrees that the project shall be delivered to the client no later than 4th May 1999. If the project is completed earlier than the date agreed to, some of the requirements mentioned under the heading "Secondary Requirements" will also be addressed.
A specification language will be designed to describe the input-output behavior of programs to the system. This language should capture the number of inputs and outputs, valid data types that may be used as program input and the data types of the program's outputs. We should also know how to invoke the program giving it a set of inputs and collecting its outputs, and whether any of the inputs or outputs is optional. The description also has to specify any flags, options or argument ordering needed to pass input files to and get output files from the program.
The user will be provided with an interface by which he can create/edit a data-flow diagram, by drawing boxes representing programs and wiring the output of one program to the input of another. The interface will also allow the user to describe programs to it, which can then be used in a data-flow diagram. It will also provide a way to run the data-flow. A scheduler program, using a description of the data-flow generated by the user interface, does this.
The system will be coded in C++ using
FLTK (a relatively new API based on OpenGL) for the user interface. This
is so that it is portable to any platform that supports some form of OpenGL.
The user creates data-flow descriptions using programs as modules. It is possible that one of these modules is itself a data-flow description. We call such modules macro-modules. The interface will allow the user to make a data-flow a macro-module and use it in data-flow diagrams.
In addition, we may allow the user
to specify a hierarchy among data types. For example, an image file is
also a byte stream. This information is useful when determining whether
the output of one program can be used as the input of another. Using the
previous example, a program that processes a byte stream can also take
an image file as its input, but a program that displays an image file,
cannot do with a byte stream.
The client agrees to aid the contractor in the design phase of the project, especially in designing the language used to describe primitive operations. He also agrees to provide the contractor with installations of FLTK on Unix as well as on Windows and a set of sample primitive operations on both these platforms that would be required for the final demonstration.
There is a slight risk which is that the user interface might get delayed because none of the contractors has much experience with FLTK or with dataflow computation. We already have three project members getting familiar with these areas.