Initial commit

1 files changed, 625 insertions, 0 deletions

diff --git a/doc/iraf92.tex b/doc/iraf92.tex
new file mode 100644
index 00000000..46558215
--- /dev/null
+++ b/doc/iraf92.tex
@@ -0,0 +1,625 @@
+\documentstyle[11pt,paspconf,epsf]{article}
+\parskip=4pt
+
+\begin{document}
+
+\title{IRAF in the Nineties}
+
+\author{Doug Tody\altaffilmark{1}}
+\affil{National Optical Astronomy Observatories, Tucson, AZ 85726}
+
+\altaffiltext{1}{NOAO is operated by AURA, Inc.\ under contract to the
+National Science Foundation.} 
+
+\begin{abstract}
+The IRAF system (Image Reduction and Analysis Facility) has been under
+development since 1981 and in use since 1984.  Currently, in 1992, IRAF is a
+mature system with hundreds of applications which is in wide use within the
+astronomical community.  After a brief look at the current state of IRAF,
+this paper focuses on how the IRAF system is expected to develop during the
+coming decade.  Certain key new technologies or trends which any new data
+analysis system will need to deal with to be viable in the nineties and
+beyond are discussed.  An overview of the planned enhancements to the IRAF
+system software is presented, including work in the areas of image data
+structures, database facilities, networking and distributed applications,
+display interfaces, and user interfaces.
+\end{abstract}
+
+\keywords {IRAF, image processing, data analysis, graphics, visualization,
+software environments}
+
+\section {Introduction}
+
+The IRAF data reduction and analysis system has been around since 1981.
+Today IRAF is a mature system with hundreds of applications which is supported
+on all major platforms.  Many institutions, projects, and individuals around
+the U.S. and the world have developed software for IRAF.  Some of these
+packages are comparable in size to the IRAF core system itself.
+
+At the present time there are half a dozen large groups developing software
+for IRAF, plus many individuals or small groups.  Coordination of the work
+being done by the large groups is the responsibility of the IRAF TWG
+(Technical Working Group), an interagency group which oversees IRAF software
+development.  Scientific review of IRAF development is provided by an IRAF
+User's Committee, which oversees IRAF as a whole and which reports to NOAO,
+by additional User's Committees reporting on the various projects developing
+large layered packages for IRAF, and by the staff and management of the
+institutions funding IRAF development.  IRAF is used primarily by the ground
+based astronomy (NSF) and NASA space astrophysics communities.
+
+A list of the IRAF layered packages currently installed at NOAO/Tucson is
+shown in Figure 1, to illustrate the variety of packages available.  This
+list is not all-inclusive, i.e., there are additional layered packages
+available for IRAF other than those shown here, which were the ones which
+happened to be installed at NOAO when this figure was prepared.  The
+standard IRAF distribution itself, consisting of the core IRAF and NOAO
+package trees, contains about 50 additional packages, or several hundred
+tasks, totaling approximately 1.3 million source lines.  The core IRAF
+system includes the IRAF system software (host system interface, run time
+and programming environments, command language and other user interfaces,
+and core applications) and is required to compile and run any layered
+software.
+
+\small
+\begin{tabbing}
+\hspace{0.3in}\=\hspace{1.5in}\=\kill
+\> adccdrom	\> tools for accessing ADC CD-ROM\\
+\> ccaccq	\> IRAF CCD data acquisition\\
+\> color	\> prototype RGB rendering tasks\\
+\> ctio		\> CTIO local tasks\\
+\> demos	\> IRAF demos\\
+\> ftools	\> FITS tools package\\
+\> grasp	\> GONG data processing (helioseismology)\\
+\> ice		\> IRAF CCD data acquisition\\
+\> iue		\> tools for importing IUE spectral data into IRAF\\
+\> mem0		\> maximum entropy image restoration\\
+\> nlocal	\> NOAO/Tucson local tasks\\
+\> nso		\> Solar astronomy\\
+\> spptools	\> SPP programming utilities\\
+\> steward	\> Steward observatory local tasks\\
+\> stsdas	\> STScI (HST) data processing\\
+\> tables	\> STScI table tools package\\
+\> vol		\> volume rendering\\
+\> xray		\> SAO x-ray data analysis package\\
+\\
+\normalsize
+\> {Figure 1.} IRAF layered packages installed at NOAO (Dec. 1992)\\
+\end{tabbing}
+\normalsize
+\vskip -12pt
+
+As of late 1992 the current release of IRAF, which is still in distribution,
+is version 2.10.  As of December 1992 there were a total of 1068 logged
+distributions of the previous version of IRAF, V2.9, of which 196
+distributions were tape distributions mailed to the user at cost, and 872
+distributions were downloaded via anonymous ftp from the IRAF network
+archive on iraf.noao.edu.  An unknown number of additional distributions
+were downloaded via DECNET network transfer (we don't know how many, as we
+log only ftp file transfers).  These statistics count only distributions
+leaving NOAO; since the system is freely available, we have no way of
+recording redistribution of the system at remote sites or within large
+institutions.  IRAF site support traffic totals over 5000 email messages or
+phone calls per year, counting both incoming and outgoing messages.  Based
+on the number of distributions and the site support traffic we estimate
+there are currently several thousand active users of IRAF.
+
+The remainder of this paper focuses on where IRAF is headed over the
+remainder of this decade.  We look first at some key new technologies that
+we feel IRAF (or any modern astronomical data analysis system) must use
+effectively to be competitive by the end of the decade.  Some pitfalls that
+we feel system developers would be wise to consider are also discussed.
+Finally, we summarize the work planned for the next few years to enhance the
+IRAF system software to meet these new challenges.
+
+\section {Key new technologies for the next decade}
+
+IRAF is a long term project.  Most of the software or hardware technologies
+upon which IRAF is based typically have a lifetime of only 5 or 10 years -
+considerably less than the expected lifetime of the IRAF software.  To
+remain up to date it is necessary to make use of new technology, but one
+must do so carefully to avoid tying the software irrevocably to a technology
+which will one day become obsolete.  It is not easy to change a large system
+once a direction has been chosen, so one must take the long term view,
+always planning 5 to 10 years in the future, trying to visualize what future
+computer systems will be like and what we want our software to look like on
+those systems.
+
+\subsection {Key new technologies}
+
+The following are some key new technologies and technological issues or
+trends which we feel any modern data analysis system should be concerned
+with.
+
+\vspace {-5pt}
+\subsubsection {User interfaces}
+
+As computer systems become more powerful, software systems are becoming
+larger and more complex.  People do a lot more with computers now than they
+did a few years ago.  Functionality and efficiency, while still important,
+are no longer the overriding concerns they once were.  The issues of
+managing complexity, and ease of use, are increasingly important concerns.
+The challenge of user interface design is to make complex systems
+comprehensible, intuitive, and easier to learn and use.  Sophisticated user
+interfaces will make our software more pleasant to use, and allow more
+complex and sophisticated applications to be written.  The days are past
+when the user interface can be taken for granted when designing new
+software.
+
+\subsubsection {High level languages}
+
+Our common everyday computers are becoming so powerful that most of the
+compute cycles now go to waste.  At the level of compiled code, our computer
+languages and software systems are becoming increasingly complex, to the
+point where it may take an expert with years of training to deal with them.
+It may be that the time is rapidly passing when casual users will do very
+much programming with general purpose compiled languages like Fortran, C,
+C++, and so on.  The trend is towards higher level interpreted languages
+which are tailored for a particular type of application.  Whether these
+languages are syntax driven, visual, or whatever does not really matter; in
+general the optimum type of language depends upon how the language will be
+used, and languages should be customized for a particular application.  In
+the future, users will still develop custom applications, but they will
+increasingly do so using sophisticated, high level, application specific
+custom languages which are embedded in feature-rich data processing
+environments.
+
+\subsubsection {Networking and distributed objects and data}
+
+Our computers are getting powerful enough that for many applications,
+further gains in compute power won't make a whole lot of difference.  A
+powerful computer and sophisticated software aren't worth much unless one
+has data or other raw information of some type to process, analyze, or
+query.  Fortunately a new way has been found to expand the capability of a
+computer system:  the growth of global networks is opening up a whole new
+dimension on what we can do with computers.  It is already the case that one
+can do wondrous things with even the simplest hand held computer - so long
+as it is connected to the global networks.  The networks give us access to
+an inconceivable amount of data or information of various types.  Not only
+do the networks provide access to vast amounts of raw information, they make
+it possible to export arbitrary {\it services} via the network.  Rather than
+export data or software, one can now export services which remote clients
+can access at runtime to do any number of interesting things.  We are only
+just starting to learn how to make use of the global networks, but it is
+already clear that the networks will change forever how we do computing, and
+how we use computers.
+
+\subsubsection {Object oriented software structure and methodology}
+
+Every few years something new comes along (e.g., AI, CASE, HyperCard, etc.)
+which proponents claim will revolutionize how we do computing.  Most of
+these ``silver bullets'', useful though they may be in some applications,
+are oversold and after a time something else gets all the press.  The latest
+such hot item is object oriented programming (OOP).  The journals are full
+of talk about object oriented languages, databases, programming tools, and
+so on.  This time it is not just another overhyped product though.  The
+object oriented approach to software development and software design is
+probably the most important development in software engineering since
+structured programming in the 80's.  In fact it is a natural outgrowth of
+the best software practices of the 80's.
+
+What is important about object orientation is not a particular language,
+commercial product, or other tool, but the concepts and methodology
+underlying the object oriented approach to software development and systems
+design.  In particular, the object oriented approach places a special
+emphasis on the {\it conceptual modeling} of the objects (classes)
+comprising a software system.  This emphasis on conceptual modeling, and the
+encapsulation or information hiding that is a natural part of the object
+oriented approach, are fundamentally important in dealing with the
+complexity of large modern software systems.  Other elements of the object
+oriented approach such as subclassing and inheritance are probably
+fundamental to a true object oriented software structure, but this is a
+fairly specific software structure, and not necessarily the best one for all
+applications.  Like any technology, OOP will be better for some things than
+for others, and we are still learning the limitations of this new technology
+and where it can be used most effectively.
+
+\subsubsection {Database technology}
+
+There is nothing very new about database technology.  To date though,
+astronomy has done little with database technology, beyond its obvious use
+for indexing data archives.  We think that there is much that could be done
+by combining, e.g., database technology with a graphical user interface to
+perform sophisticated queries of the catalogs produced by astronomical
+analysis programs such as are produced by image classification, source
+detection, and stellar or galaxy photometry programs.  Furthermore our data
+sets are becoming larger and increasingly more complex, as is the way we
+access data, especially when we take network access to remote databases into
+account.  Database technology will eventually have to be brought into play
+to effectively manage this increased complexity.  Conventional relational
+database technology will continue to be important for large data archives
+and for some types of catalogs produced by analysis programs, but object
+oriented database techniques will be better suited to the complex data
+objects dealt with by our online analysis systems.
+
+\subsection {Concerns}
+
+In the process of employing all this new technology there are a number of
+things to watch out for.
+
+\subsubsection {The coming OS wars}
+
+UNIX is king right now, but will this be the case ten years from now?  Ten
+years ago the dominant system in astronomy was the VAX running VMS.  Today
+it is the UNIX workstation.  UNIX is a very good system and it (or more
+properly its descendents) might still be the dominant system ten years from
+now, but this is by no means certain.  There is a very real possibility that
+the dominant system for astronomers ten years from now could be the PC.  Not
+the PC we have now, but the PC we will have then, when a PC is more powerful
+than the workstation of today, cheaper, portable, fully connected to the
+networks, and capable of running ``shrink wrapped'' personal applications in
+addition to specialized astronomical software.  The engineering workstations
+and servers of today will still be around, and they will be more powerful
+than ever, but an increasing share of scientific computing is likely to be
+done on mass market PC systems.
+
+If the PC does so well then we cannot be certain that UNIX will still be the
+predominant operating system ten years from now.  We might instead be using
+an operating system which was designed for the mass market, such as
+Windows/NT, or conceivably even some future version of MacOS (most likely a
+mixture of all these).  UNIX may be more powerful, more elegant, more
+technically superior, and less proprietary, but those criteria will not
+necessarily prove as compelling to the mass markets as they have to the
+academic and engineering markets.  Even within the UNIX community there is
+still considerable variation in what we call UNIX, and despite efforts like
+POSIX there is no real evidence that this situation will ever change.  On
+the contrary, UNIX systems are becoming increasingly complex and small
+differences are correspondingly magnified.
+
+\subsubsection {Window systems}
+
+In the past the main concern when porting software to a new platform was the
+operating system.  Operating system differences are still a concern, but not
+as big a concern as in times past.  A possibly more significant problem, and
+one which is perhaps being overlooked by many folks now writing software, is
+the window system, or in the case of X, the window system toolkit.  Modern
+window systems are comparable in complexity to operating systems but the
+technology is much newer, and is still evolving rapidly.  It is likely that
+any window system specific software written today will have to be thrown out
+and rewritten a few years from now.  Most window system specific software
+today would have to be largely rewritten to ``port'' the application to a
+different window system on a different platform.  Despite these problems,
+most window system applications written today are monolithic applications
+with the application specific functions and user interface code tightly
+interwoven.  Window systems may prove to be the ``assembly language'' of the
+90's.
+
+\subsubsection {Computer languages}
+
+In the past ten years the major players in the general computer languages
+arena have changed, but the game has not.  We have seen Fortran 77, K\&R C,
+ANSI C, Fortran 90, and lately C++, with others such as Ada, Pascal, and
+Objective C on the sidelines.  Computer languages are constantly evolving.
+Even given language standards, implementations of a language by vendors on
+different hardware vary considerably.  This is unlikely to ever change.
+
+The evolution of computer languages is not a problem so long as one is
+content to write disposable software.  If the projected lifetime of a body
+of software is ten years or longer, and the body of software is large enough
+that rewriting it may not be practical, the evolution of languages is a
+serious problem which may eventually cause the software to become obsolete,
+along with the technology it has been tied to.  Even in the short run, the
+variation in language implementations on different platforms can be a
+serious support headache if the body of code is sufficiently large.
+
+\section {Major IRAF system software enhancements}
+
+In this section we describe the work being done to enhance the IRAF system
+software.  This is a long term effort extending over a period of years.
+Some of the work discussed has already been completed, but much of it is
+either in progress or still to be done.
+
+The work presented here attempts to exploit the new technologies discussed
+in the last section, while avoiding the pitfalls that can come from tying
+software too closely to a particular technology.  Existing technology is
+only useful up to a point; much of the work discussed in this section is an
+outgrowth of the work already done on the IRAF system, and reflects problems
+some of which appear to be unique (at some level) to astronomical data
+analysis.
+
+The reader is assumed to already have some familiarity with the current IRAF
+system software.  The software described here is very extensive and it is
+impossible in a short review article like this to go into very much detail,
+or explain all the terminology used.
+
+\subsection {Image Structures}
+
+The term ``image structures'' refers to the representation of the primary
+data type in IRAF, the {\it image}.  In IRAF an image is not a simple
+picture, but an arbitrarily complex data object.  An image consists of an
+N-dimensional logical data raster (sampled data array) plus various bits of
+associated information, some of which may be quite complex objects in their
+own right.  The logical data raster need not be physically stored as a
+sampled data array, for example in the case of event data the data is stored
+as an event list and sampled only when the image is accessed.  The
+information often associated with a data raster includes history
+information, any attributes computed by analysis of the image data, world
+coordinate systems, pixel or region masks, uncertainty or "noise"
+information, and so on.
+
+A common example of an image is a raw data image, i.e., an astronomical
+observation.  Examples of raw data images are a 1D spectrum, a 2D CCD data
+frame, or a 3D Fabry-Perot or radio spectral image cube.  Images of
+dimension higher than 3 are rare in astronomy.  Typical astronomical data
+sets can be quite large, e.g. several gigabytes, perhaps consisting of
+thousands of small spectra, or several hundred large 2D images.  Individual
+images of 32 megabytes or larger are occasionally seen.
+
+\small
+\begin{tabbing}
+\hspace{0.3in}\=\hspace{0.3in}\=\hspace{0.3in}\=\hspace{2in}\=\kill
+\>{\bf high level image class}\\
+    \>\>{\tt IMIO}                \>\>image i/o\\
+\\
+\>{\bf image header access}\\
+    \>\>{\tt IMIO}                \>\>header access\\
+	\>\>\>{\tt DFIO}          \>datafile manager (*)\\
+	\>\>\>{\tt FMIO}          \>file manager\\
+\\
+\>{\bf image kernels} (internal to IMIO)\\
+    \>\>{\tt IKI}                 \>\>image kernel interface\\
+	\>\>\>{\tt OIF}           \>old (original) image format\\
+	\>\>\>{\tt STF}           \>HST image format\\
+	\>\>\>{\tt PLF}           \>pixel list image format\\
+	\>\>\>{\tt QPF}           \>QPOE (event list) image format\\
+	\>\>\>{\tt FTF}           \>FITS image format\\
+	\>\>\>new format          \>new DFIO based image format (*)\\
+	\>\>\>others              \>HDS(?), ``PC'' image formats (*)\\
+\\
+\>{\bf auxiliary classes}\\
+    \>\>{\tt MWCS}                \>\>world coordinate systems\\
+    \>\>{\tt PMIO, PLIO, MIO}     \>\>pixel masks or lists\\
+    \>\>{\tt QPOE}                \>\>event list data files\\
+    \>\>{\tt NFIO}                \>\>noise function package (*)\\
+\\
+\> \normalsize {Figure 2.} New Image Structures\\
+\end{tabbing}
+\normalsize
+\vskip -12pt
+
+When IRAF was first released some years ago the only image format consisted
+of a pair of files per image, one for the header and one for the pixel
+matrix, with the header file consisting of a fixed binary structure plus a
+variable number of FITS cards (not a terribly flexible or efficient
+structure).  Over time several alternative image formats have been added, as
+well as support for some of the auxiliary data objects associated with
+images.  It has become increasingly difficult to store all this information
+in the simple data structures provided by the older IRAF image formats.  The
+purpose of the new image structures project is to provide a general, well
+integrated hierarchy of image object classes for flexibly and efficiently
+representing a wide variety of image data.
+
+The major components of the new image structures are summarized in Figure
+2.  The new image structures project is further along than most of the other
+new software discussed in this paper; everything listed has been implemented
+except for the items marked with an asterisk.  This is a {\it big} project;
+some of the subsystems listed here, e.g., MWCS, QPOE etc., are major
+projects in their own right, and in total the new image structures code
+will likely exceed 100K lines, not counting the lower level IRAF classes
+or other library code.
+
+A key feature of the implementation of the image interface in IRAF is the
+{\it image kernel}.  An image kernel is the only part of IRAF that knows
+anything about how an image is stored externally, i.e., the physical image
+format.  The image kernel implements a mapping between the physical image
+format and the logical view of an image implemented in the runtime image
+descriptor used to access an active image object.  The image kernel can
+provide a standard interface to a wide variety of image types, including odd
+things like photon event lists, image masks, or image display server frame
+buffers, in addition to various standard image raster disk file formats.  In
+principle IRAF can be integrated with any external image processing system
+by implementing an IKI image kernel for the image format defined by the
+external system.  The best example of this is FITS.  The FITS image kernel
+also allows archival data, e.g. on CD-ROM or on a remote network server, to
+be directly accessed by IRAF programs.
+
+The main work remaining to be done to finish the new image structures
+project is to implement a new standard IRAF online image format based on the
+general datafile manager (DFIO, discussed in the next section).  This will
+replace the existing OIF image format.  The new format will make it possible
+to simply and efficiently group complex objects such as world coordinate
+systems, pixel masks, and compressed pixel uncertainty arrays with pixel
+arrays to form the objects we call images.
+
+\subsection {Database facilities}
+
+Managing complex data structures such as the image structures in a flexible
+and efficient manner, while providing features such as data independence,
+machine independence, a data recovery capability, transparent storage of
+arbitrarily large data elements, capabilities for storing complex objects
+(not just simple tables), indexing for efficient lookup, and a good
+integration with the higher level IRAF software, is a complex and demanding
+problem.  The low level interface planned to provide this capability for
+IRAF is DFIO, the data file manager.  DFIO is layered upon FMIO, the file
+manager, which is in turn layered upon IRAF binary file i/o (FIO).  DFIO is
+a medium level interface designed for embedded applications, e.g. it will
+be used internally within IMIO to store image data.  For the most part IRAF
+applications will not use DFIO directly, rather they will deal with data at
+a higher level, e.g. via the image class.
+
+One of the types of data DFIO will be capable of storing is the table, as in
+a relational database.  Hence, in addition to its use as an embedded
+interface within IRAF system software to store complex data objects, DFIO
+will provide a traditional relational database capability for applications
+such as catalog access.  Since IRAF already provides a builtin networking
+capability, DFIO will automatically be usable in client-server applications
+to provide a distributed database facility.  To be able to access external,
+non-IRAF databases, a database server architecture will be used (similar to
+the use of image kernels by IMIO).
+
+\subsection {Networking and distributed applications}
+
+Networking is an integral part of IRAF and IRAF has always been able to
+support distributed applications.  In IRAF all access to external resources
+is via the IRAF kernel.  The IRAF kernel has a builtin remote procedure call
+facility allowing kernel procedures to execute either locally or remotely.
+(This includes {\it all} kernel procedures that access a named external
+resource, be it a file, directory, tape drive, image display, process, or
+whatever).  In a local reference the procedure is executed directly; when
+the resource being accessed resides on a remote node a custom RPC protocol
+layered upon the IRAF networking driver is used to remotely execute the
+kernel procedure.  The only system dependent part of all this is the
+networking driver, which can use any standard message or stream oriented
+transport layer, e.g.  TCP/IP, DECNET, and so on.  Since the IRAF kernel
+provides a standard host interface, the routing or leaf nodes in a
+distributed IRAF process tree can execute on host machines running any
+operating system to which IRAF has been ported.  It is even possible to
+transparently route RPC calls between different networks, e.g. the Internet
+and SPAN.
+
+There are still some significant enhancements planned for the IRAF
+networking system but these are for the most part comparatively minor
+evolutionary enhancements.  One of the most interesting enhancements being
+considered is some sort of interface to non-IRAF servers, e.g. ftp or WAIS
+servers.  This would not provide the full capability of the IRAF kernel, but
+might work for simple directory and file access, and would allow any IRAF
+application to transparently access arbitrary servers on the network whether
+or not they provide an IRAF kernel server.
+
+\subsection {User Interfaces}
+
+In general, the IRAF system circa 1992 is very strong in terms of the
+functionality provided, but is weak in the area of user interfaces.  This
+directly reflects the priorities for IRAF development in the late 1980's,
+which emphasized getting numbers out of the data.  This meant new
+applications, and due to the common environment, enhanced system support for
+these applications (e.g. the new image structures).  In the early 1990's,
+with a wealth of software now in the system and more people than ever using
+IRAF, the emphasis has shifted towards ease of use and improved user
+interaction and data display.
+
+Enhancements to the IRAF user interfaces are planned in many areas.  Two of
+the most exciting are a general GUI (graphics user interface) capability,
+available to any IRAF application and capable of making full use of the
+advanced capabilities of modern window systems, and less obviously, something
+called minilanguage support.
+
+Modern window systems are remarkably complex software systems, and the field
+is still evolving rapidly, with many quite different window systems and
+window system toolkits being developed or in use.  Using window user
+interfaces effectively in scientific applications is challenging, as if one
+is not careful and the wrong approach is taken, programmers may spend all
+their time struggling with complex window system software and not get any
+science software written.  Due to the complexity of the field, learning a
+particular toolkit or user interface builder is time consuming and a
+considerable investment in time is required to make use of any particular
+tool.  A wrong decision could result in a great deal of wasted time,
+particularly for a large project where many people may be developing
+software.
+
+%\small
+%\begin{verbatim}
+%         IRAF application  <---- (file defining user interface)
+%             |     |
+%            GIO    |
+%             |     |
+%           Interpreter  <====== IPC =======>  Interpreter
+%                                                   |
+%                                             Object Manager
+%                                                   |
+%                                           Window System Toolkit
+%
+%         (Client Application)                (Widget Server)
+%\end{verbatim}
+%\normalsize
+%
+%\hspace{0.3in}{Figure 3.} Widget Server Architecture
+%\vspace{12pt}
+
+\begin{figure}
+\epsfxsize=5.0in \epsfbox{iraf92f3.eps}
+\hspace{0.3in}{Figure 3.} Widget Server Architecture
+\end{figure}
+
+After considerable time spent studying window systems and graphics user
+interfaces we think we have found a solution to this problem.  It is called
+the {\it widget server}.  In the widget server architecture the application
+and the user interface are in two separate processes.  The application is a
+type of minilanguage with a simple parsed command line interface.  The user
+interface resides in the widget server process.  When an application starts
+up it downloads a text file to the widget server containing the user
+interface to be executed.  This defines all the widgets forming the user
+interface as well as the code to be executed (interpreted) while the user
+interface executes.  During execution, the user interface (widget server)
+and client application exchange commands and data via interprocess
+communication.
+
+This architecture has many advantages, e.g., a complete separation of the
+user interface and functional code, and a high level interpreted interface
+to the window system for the programmer, making it easy to develop GUIs (and
+easy for the user to customize the user interface).  Since only the widget
+server knows about a particular window system or toolkit, the widget server
+also provides window system and toolkit independence, allowing a new window
+system or toolkit to be supported merely by implementing a new version of the
+widget server.  The widget set provided by the widget server will include
+the standard toolkit text, button, scollbar, list, geometry, etc. widgets,
+plus some custom widgets (such as graphics and image display widgets)
+tailored to IRAF applications.
+
+As powerful as the graphics user interface can be, it is not the only way to
+do a user interface, nor is it necessarily the best type of user interface
+for all interactive applications.  A quite different type of applications
+user interface which is at least as powerful, and also well suited to
+complex applications, is the context-based minilanguage.  A minilanguage is
+a single program (IRAF task) with a syntax driven, command line user
+interface.  The program maintains an internal state and successive input
+statements modify this state.  The syntax, command or function set, and
+internal data structures are customized for each application.  The
+individual functions are usually simple, but arbitrarily complex operations
+can be performed by stringing together sequences of commands or
+expressions.  By designing an appropriate syntax very powerful
+applications-specific languages can be devised.
+
+A good language will be extensible, allowing users to define new procedures,
+link to external compiled routines, or interface external IRAF or host tasks
+so that they appear as functions in the minilanguage.  It will even be
+possible to combine a graphics user interface with a minilanguage.  For
+example, the combination of the widget server with a minilanguage will
+provide both a fully featured GUI capability and a powerful interpreted
+computing engine, both programmable by the user without need to resort to
+low level compiled languages.  When all this is layered upon the IRAF
+environment, providing well integrated access to powerful facilities such as
+the IRAF image structures and a wealth of existing external tasks, the
+result will be high level applications of unprecedented power, flexibility,
+and sophistication.
+
+\vspace{12pt}
+\acknowledgments
+
+Without the contributions of many people over the years, the IRAF system we
+have now would not exist.  The author particularly wishes to thank Frank
+Valdes and Lindsey Davis of the NOAO IRAF group, who wrote much of the IRAF
+software.  STScI and SAO have made major contributions to the system over
+the years and the IRAF project would not be the same without their
+involvement.  A grant from the NASA astrophysics data program has made all
+the difference as IRAF use continued to grow while the NOAO budget continued
+to shrink.  Finally, we wish to thank the NOAO directors and scientific
+staff for their continuing support and enthusiastic use of IRAF, and for
+their help in making IRAF a better system.
+
+\begin{references}
+\reference Tody, D., 1986, ``The IRAF Data Reduction and Analysis System'',
+in {\it Instrumentation in Astronomy VI}, David L. Crawford, Editor.
+
+\reference
+Hanisch, R. J. 1991,
+``STSDAS:  The Space Telescope Science Data Analysis System'',
+in {\it Data Analysis in Astronomy IV} (Di Ges\`{u}, V.,
+Scarsi, L., Buccheri, R., Crane, P., Maccarrone, M.C., and Zimmermann, H.U.,
+eds., Plenum Press, New York), 97.
+
+\reference
+Worrall, D.M., Conroy, M., DePonte, J., Harnden, F.R., Mandel, E.,
+Murray, S.S, Trinchieri, G. , VanHilst, M. , Wilkes, B.J., 1992,
+``PROS: Data Analysis for ROSAT''
+in {\it Data Analysis in Astronomy IV}, eds.~V. Di Gesu {\it et al.},
+Plenum Press, 145.
+
+\reference Olson, E. C. and Christian, C. A., 1992,
+``The EUVE Guest Observer Analysis Software.''
+in {\it Astronomical Data Analysis Software and Systems I}.
+
+\reference See also the many technical papers describing the IRAF software,
+available in {\tt iraf.noao.edu:iraf/docs}.
+
+\end{references}
+\end{document}