Using the Computer to Communicate: Creating a Computerized Conferencing System on UNIX

(1)

NOT FOR QUOTATION WITHOUT PERMISSION OF THE AUTHOR

USING THE COMPUTER TO COMMUNICATE:

CREATING A COMPUTERIZED CONFERENCING SYSTEM ON UNIX

Michael M.L. P e a r s o n J a m e s

E.

Kulp

November 1980 WP-80-159

W o ~ k i n g Pupers a r e interim r e p o r t s on work of t h e I n t e r n a t i o n a l I n s t i t u t e for Applied S y s t e m s Analysis a n d have received only limited review. Views or opinions e x p r e s s e d h e r e i n do n o t necessarily r e p r e s e n t those of t h e I n s t i t u t e or of its National Member Organizations.

INTERNATIONAL INSTITUTE FOR APPIJED SYSTEMS ANALYSIS

(2)

PREFACE

This p a p e r was prepared for the International Symposium on Computer Message Systems, Ottawa, Canada, April 6-8 1981. I t is one of a series produced b y IIASA's Survey Project in cooperation with t h e Computer Ser- vices D e p a r t m e n t on t h e topic of using t h e c o m p u t e r t o communicate.

Our a i m is t o m a k e t h e IIASA computer m o r e accessible t o IIASA scientists for a wide range of people-oriented activities: computer-based t e x t editing and t e x t formatting, decision support systems, computerized conferencing, multi-author manuscript preparation, and other operations promoting international t e a m r e s e a r c h among widely dispersed research- ers.

For r e a d e r s unfamiliar with IIASA and t h e Survey Project we offer t h e fol- lowing two p a r a g r a p h s for a b e t t e r understanding of t h e institutional con- t e x t of this paper.

The International Institute for Applied Syste~ns Analysis (IIASA) is a n in- terdisciplinary, nongovernmental r e s e a r c h institute, c h a r t e r e d in Oc- tober, 1972 upon t h e initiative of t h e academies of science or equivalent institutions of twelve nations ( t h e r e a r e now seventeen National Member Organizations). By applying systems analysis, its staff of scientists from East and West is seeking t o gain a b e t t e r understanding of i m p o r t a n t con- t e m p o r a r y problems resulting from scientific and technological develop- m e n t . 11ASA conducts m u c h of its r e s e a r c h in cooperation with other r e s e a r c h and policymaking organizations worldwide.

(3)

The IIASA Survey Project-a project to survey the s t a t e of the a r t of ap- plied systems analysis-was established to promote the development of applied systems analysis and to disseminate its methods and approaches.

The Project seeks t o encourage the widespread and b e t t e r application of systems analysis t o problems of international relevance; t o improve analytical techniques and their usefulness to decision processes; to con- tribute to t h e education in systems analysis of the expert and the in- terested nonexpert. To pursue these objectives it is: 1) publishing a series of books on applied systems analysis, 2) writing a Handbook of A p - plied Systems Analysis in three volumes, and 3) conducting research into the craft of applied systems analysis.

(4)

USING THE COMPUTER TO COMMUNICATE:

CREATING A COMPUTERIZED CONFERENCING SYSTEM ON UNIX

Michael M.L. Pearson, and James E. Kulp

INTRODUCTION

This paper discusses a computerized conferencing s y s t e m being developed a t our institute. I t does not describe t h e system. For a description we refer t h e r e a d e r elsewhere (see Pearson and Lathrop, 1980). The system, which we call Telecenter, is similar t o o t h e r s of its genre; using it one can c r e a t e conferences, add participants, e n t e r new conference comments, modify old comments, learn who has s e e n which c o m m e n t s in any given conference, g e t an overview of one's own s t a t u s in all one's own conferences, and so forth.

Telecenter's c u r r e n t form, however, is not t h e topic of this paper. What we wish t o a d d r e s s h e r e is hqw and why Telecenter was developed. The "how" has t o do with our U N Z operating system a n d is t h e subject of P a r t Two. The "why" has t o do with our users and t h e i r needs a n d is addressed in P a r t One. Regarding both users and UNIX, we have t r i e d t o conform to c e i t a i n general principles recognized by o t h e r s involved in designing and implementing computerized conferencing sys- t e m s , office automation and decision s u p p o r t systems. One result, we believe, is t h a t we have m a d e considerable strides with surprisingly few resources. For example, Telecenter itself was c r e a t e d with approximately one man-week's programming effort. This is noteworthy considering t h e usual requirements for developing such a system. Murray Turoff, a pioneer in the field of computerized conferencing writes in The N e t w o r k N a t i o n :

3 UNIX is a t r a d e m a r k of Bell Laboratories.

(5)

A t t h e moment, most of the (computerized conferencing) sys- t e m s t h a t have been implemented r e p r e s e n t many person-years of programming effort. There is no suitable higher-level language t h a t allows a concise and appropriate specification of a human communication process. All c u r r e n t efforts a t using FORTRAN, APL, BASIC, etc. a r e like describing a picture of t h e Mona Lisa in words only

...

Currently we a r e beginning t o under- s t a n d the basic functions t h a t characterize conferencing sys- t e m s and it can be expected t h a t a computer language will evolve t h a t c a n allow t h e s e systems to be c r e a t e d in a few person-months of effort (Hiltz and Turoff, p. 391).

The kind of higher-level language for human commur&cation processes t h a t Turoff speculates about has yet t o be invented. Relevant t o this s t a t e m e n t , however, is t h e fact that software tools used to construct conferencing systems a few years ago a r e inferior t o tools developed more recently. That Telecenter was made operational so quickly is primarily t h e result of its having been fashioned under a n interactive and compara- tively state-of-the-art time-sharing operating system, but it is also partly t h e result of our attitude toward user needs.

USERS' NEEDS: THE " W H Y

OF

TELECENTER

* *

Since the r e s e a r c h project where one of t h e authors works is primarily a publishing activity, his first involvement with computerized conferencing was in the specialized form he t e r m s "computerized manuscript conferencing," t h e use of computer conferencing mechan- isms t o facilitate t h e joint authorship of manuscripts ( s e e Pearson, 1980a). Presently his i n t e r e s t s have broadened t o include any application of computerized-conferencing-type tools t o facilitate applied systems analysis and institute research, what he, for want of a b e t t e r t e r m , calls

"using t h e computer t o communicate" (see Pearson, 1980a, Pearson and Lathrop 1980 a n d Pearson 1980b). Manuscript conferencing remains cen- tral t o t h e project's teleconferencing interests since a large percentage of the institute's r e s e a r c h involves writing, but it is now a p a r t of a more general activity whose goal is t o explore t h e possibilities of a new kind of

*

The closest thing in spirit t o it with which we a r e familiar is a proposal by Richard Miller t o use Backus Normal Form (BNF) representations ( t h e formalism originally c r e a t e d to describe ALGOL) for functional descriptions of an electronic message system (EMS). Miller s t r e s s e s the need for a formal description, or a t least some consistent s e t of definitions, of the functions and interactions of electronic message systems, and sees the BNF- type formalism a s a starting point for a "common language in which various (electronic message) systems can be conceived., characterized, compared and evaluated." He goes on t o say, "A formal representation of t,he user environment could benefit t h e EMS field t o the same extent t h a t compiler theory 20 years ago made an impact on the rapid development

of

high-level computer languages."

The Survey Project, a p a r t of t h e institute's General Iiesearch program (see Preface).

(6)

cornputing//communications environment-one which should b e able t o significantly e x p e d i t e scientific work among institule slaff s e p a r a t e d in t i m e and/or s p a c e , a n d a t t h e s a m e t i m e b e accessible t o t h e average r e s e a r c h e r .

I t is o u r belief t h a t t h e b e s t way t o explore "using t h e c o m p u t e r t o c o m m u n i c a t e " for scientific r e s e a r c h a t o u r i n s t i t u t e is t o facilitate it for t h e applications of individual scientists. Thus a s a tool-environment, Telecenter offers a s e t of potentials t h a t we d o not fully u n d e r s t a n d a n d will n o t fully u n d e r s t a n d until we involve u s e r s a n d t h e i r own potentials a n d s e e how m a t t e r s evolve. I t is t h e s e u s e r s , t h e IIASA s c i e n t i s t s a n d t h e i r applications, t h a t we m u s t serve in o r d e r t o m a k e this m e d i u m serve applied s y s t e m s analysis.

Under n o c i r c u m s t a n c e s do we want t o c r e a t e a n e l a b o r a t e piece of m a c h i n e r y on t h e basis of our, undoubtedly p r e m a t u r e , p e r c e p - tions a s t o what is b e s t for i n s t i t u t e staff. Hence t h e need for modules, a d a p t a b l e functions, t h a t we c a n offer a s preliminary tools t o individuals for whom it is n o t fully c l e a r a t t h e o u t s e t in which direction t h e i r activity will t a k e t h e m .

W e a g r e e e n t i r e l y with what Uhlig, F a r b e r a n d Bair s a y regarding t h e i m p l e m e n t a t i o n of c o m p u t e r s y s t e m s for t h e "Office of t h e F u t u r e "

a n d t h i n k it especially applicable t o s y s t e m s s u c h a s Telecenter-:

Too often s y s t e m s a r e built t o be u s e d by a n d for t h e i r ciesigners-not by t h e u l t i m a t e users. W e c a n s e e this in m a n y c u r r e n t s y s t e m s . Also we t e n d to a s s u m e t h a t t h e world will s t o p a n d wait for o u r s y s t e m s t o be fixed a n d t h a t t,he u s e r s will be t o l e r a n t of loss of inform.ation. Many of t h e s y s t e m s of t h e fu- t u r e will b e u s e d n o t by c o m p u t e r people b u t by exzcutives, b y t.he public, a n d by policy m a k e r s . (Uhlig, et al., p. 153)

It should b e s t r e s s e d t h a t we a r e by no m e a n s cert.ain t h a t a c o m p u t e r i z e d conferencing systern offers t h e b e s t solutions t o t h e problems of facilitating joint r e s e a r c h electronically. Our p r i m a r y objective is facilitating r e s e a r c h , n o t c r e a t i n g a c-onferencing s y s t e m . It m a y be a m i s t a k e , for example, t o t r y a n d enforce t h e s t r u c t u r e d notion of conferences-topic o r i e n t e d discussions-on t h e normally fluid c o m m u n i - cations habits of m o s t r e s e a r c h e r s . Or it m a y b e futile only i n s o m e c a s e s , n o t in o t h e r s , depending on t h e individuals involved a n d t h e t a s k a t hand. It is m o s t likely t h a t we n e e d a n environment t h a t i n t e g r a t e s conferencing, c o m p u t e r - m a i l funct,ions a n d o t h e r c o n i p u t e r - b a s e d tools-text processing, d a t a b a s e use, computational r o u t i n e s , a n d so forth. The irn- p o r t a n t thing is t o have a facility up a n d running t h a t c a n b e a d a p t e d t o u s e r needs.

Thus, Telecenter is not primarily t h e k e r n e l of a t e l e c o n f e r e n c - ing s y s t e m , b u t , r a t h e r , a s e t of modifiable functions t h a t c a n s e r v e a s a s t a r t i n g point in s e a r c h i n g for a suitable environin.ent for "using t h e c o m - p u t e r t o communicate". I t is import,ant t h a t t h e s e functioris c a n b e p a c k - aged in a single, c o n s i s t e n t , easy-to-use s y s t e m such a s T e l e c e n t e r b u t

(7)

even more i m p o r t a n t t h a t t h e y exist as modules t h a t c a n be modified and combined in different ways for different purposes. Of all t h e computer-based, person-to-person communications tools we a r e familiar with, computer c o n f e ~ e n c i n g s e e m s t h e most accessible t o people unfamiliar with computers. It is for this reason we began with a g e n e r a l com- p u t e r conferencing schema.

SERVICE AS ANOTHER WORD FOR AVAILABILITY

Our point of d e p a r t u r e in exploring t h e potential of "using t h e c o m p u t e r t o communicate" a t our institute has been t h e user. Similar kinds of a t t i t u d e s have e m e r g e d from decision s u p p o r t s y s t e m (DSS) r e s e a r c h . Consider Gambino and Keen's admonitions t o ' l e a r n t h e language of t h e g r o u p you a r e supporting, and develop command functions for it. "build a capability r a t h e r t h a n a product"; s u p p o r t first and extend l a t e r (as inexpensively a s possible); select innovative, creative u s e r s with something a t stake; s u p p o r t t h e person r a t h e r t h a n solve t h e problem or build a model; encourage feedback and respond t o u s e r ideas a n d r e q u e s t s (see Gambino).

And i t is our experience t h a t , providing t h e u s e r is motivated and has a n i m p o r t a n t job t o do, the single most i m p o r t a n t f a c t o r influenc- ing t h e success o r failure of an activity is availability. This concept runs as a common t h r e a d through all phases of implementing t h e computer/communications environment mentioned above-from t h e simple existence of Telecenter (before i t we had nothing we could use locally) t o documentation of facilities, guaranteeing acceptable response time ( t h e single biggest problem t o d a t e in promoting use of t h e system; other imperfections in t h e s y s t e m have b e e n in'significant factors compared t o this) and a c c e s s t o terminals.

A corollary t o availability is adaptability. If a user needs a c e r - tain f e a t u r e available in o r d e r t o do t h e job a t hand b e t t e r , Telecenter m u s t provide it-adapt t o t h e user's need. This fact, even more t h a n t h e issue of cost, precluded our turning t o already existing conferencing sys- t e m s . Most were not portable: t h e y were written in impossible-to-modify assembler language or in large, unwieldy programs in higher-level programming languages t h a t were unsatisfactory. Some constituted whole systems-worlds unto themselves-and none was suitable for integration into o u r institute's computing environment. We needed something we could quickly implement, u n d e r s t a n d and adapt.

a Turoff's EIES system, in particular, has d e m o n s t r a t e d how with forgiving software a n d conscientious on-line consultancy services a system of this kind c a n acquire a large constituency, including a large n u m b e r of people who have never used a c o m p u t e r before (see Hiltz and Turoff). The com- mercial computerized conferencing service, Infomedia, has also achieved success in this a r e a . Infomedia's approach h a s been t o offer very easy- to-use software t o its c u s t o m e r s (see Planet News, its monthly newsletter).

(8)

An individual will only use a c o m p u t e r s y s t e m s u c h a s Telecenter when i t is preferable t o competing tools s u c h a s pencil, telephone, l e t t e r s , telex, a s s i s t a n t s , a n d s o on. In DSS terminology, t h e s y s t e m is discretionary-it is a t t h e discretion of t h e user/decision m a k e r whether o r n o t t o employ i t ( s e e Sprague).

We c a n l e a r n a n u m b e r of lessons from DSS designers a n d imple- m e n t o r s . Telecenter-type functions could, we think, evolve into a communications tool with significant DSS components, although a t p r e s e n t it is n o t a DSS; i t s p r i m a r y purpose is n o t offering models a n d d a t a b a s e s t o help m a n a g e r s m a k e decisions. Nevertheless, Telecenter's relation t o i t s u s e r s is analogous t o t h a t of a DSS t o i t s users. The DSS notion of adaptive design, for example, is applicable t o o u r a p p r o a c h . As S p r a g u e says, i t involves:

(1) Identifying a critical subproblem (2) Building a n initial systern

(3) Using and evaluating

(4) Adding a n d deleting capabilities (5) Repeating 3 & 4

Similarly, a s far a s Telecenter's development is c o n c e r n e d , t h e c o n c e p t of a DSS g e n e r a t o r , a n d t h a t of DSS tools, b o t h have close paral- lels with, respectively, t h e s c r i p t m e c h a n i s m of t h e UNlx c o m m a n d in- t e r p r e t o r (see below) a n d t h e U N X operating s y s t e m s itself. In DSS terminology, t h e DSS g e n e r a t o r is t h e vehicle t h a t p e r m i t s t h e builder of a specific DSS do his job quickly and efficiently without having t o have t h e c o m p u t e r expertise of a s y s t e m s p r o g r a m m e r . Thanks t o t h e DSS gen- e r a t o r , t h e builder can devote himself exclusively t o decision t a s k s at hand-analyzing applications issues and responding t o t h e m . "DSS tools"

a r e t h e p r o d u c t s of t h e s y s t e m s p r o g r a m m e r ( t h e "toolsmith") t h a t per- m i t t h e e x i s t e n c e of t h e DSS-generator facility.

An i m p o r t a n t issue h e r e is willingness t o t r a d e off responsive- n e s s t o u s e r n e e d s against polish in final design. I n s t e a d of dedicating all r e s o u r c e s t o t h e c r e a t i o n of a perfect., fully designed s y s t e m , t h e ap- p r o a c h is t o devote, say, fifty p e r c e n t of one's r e s o u r c e s t o initial systern design a n d implementation t h e n devote t h e remaining fifty p e r c e n t t o a labor intensive service activity t h a t modifies t h e s y s t e m while simultanc- ously working with e n d users. Thus we have found t h a t a large c o m p o n e n t of r e s e a r c h into t h e usefulness of this new m e d i u m is service--the promo- tion of availability in i t s b r o a d e s t sense. I m p l e m e n t a t o r s m u s t have a s t h e i r p r i m a r y perspective, a n d responsibility, b o t h facilitating and exper- imenting with t h e use of s u c h tools t o assist r e s e a r c h e r s . The luxury of a flexible a n d adaptable s y s t e m does n o t s p a r e one t h e e x p e n s e of h u m a n t i m e s p e n t directly assisting u s e r s during m a n y sessions.

(9)

USING U N M

TOOIS: THE "HOW" OF TELECENTER

After pointing o u t t h e significance of declining costs of hardware in t h e microelectronics field for forthcoming developments i n "Office of t h e Future" technology, Uhlig. F a r b e r a n d Bair g o on t o say:

However in o r d e r t o effectively utilize all t h i s c h e a p Logic we m u s t r e d u c e t h e cost of t h e software. We m u s t c r e a t e s i m p l e r s y s t e m s t h a t c a n be built reliably with small software in- vestments. S o m e of t h e things t h a t c o n t r i b u t e t o declining c o s t s a r e utilizing single-task-machine approaches. This vastly simplifies t h e c o s t of software. In addition having simple inter- faces simplifies t h e overall task. F u r t h e r m o r e , t h e adoption of simpler p r o g r a m s t r u c t u r e s will vastly e a s e t h e t a s k of t h e pro- g r a m m e r . The use of highly modular code m a y i n c r e a s e t h e u s e of cycles (which a r e c h e a p ) b u t will g r e a t l y r e d u c e t h e c o s t of software complexity. The use of s t r u c t u r e d coding technology will also c o n t r i b u t e t o t h e reduction of t h e c o s t of p r o g r a m m i n g . But p e r h a p s t h e g r e a t e s t contribution t o reducing software c o s t s in t h e Office of t h e F u t u r e will be t o c r e a t e a b e t t e r software development environment, i.e., m o r e and b e t t e r tools p r e s e n t e d in a fashion t h a t m a k e s t h e m always available t o t h e p r o g r a m m e r s . (Uhlig, e t al., p. 173)

As f a r a s t h e c r e a t i o n of T e l e c e n t e r is c o n c e r n e d , we believe t h a t UNM of- f e r e d o n e s u c h " b e t t e r software development environment" a n d t h a t four of its f e a t u r e s d e s e r v e mention in this regard:

(1) ^{i t s}u t i l i t y p r o g r a m s a n d t h e philosophy behind t,hem, (2) i t s c o m m a n d i n t e q r e t e r ,

( 3 ) t r a n s p a r e n c y between functions i m p l e m e n t e d a t different levels of software, a n d

(4) it.s h i e r a r c h i c a l f i l e s y s t e m .

U t i l i t i e s

Although he is focussing primarily on tools for making compilers (for example, a lexical analyzer and a p a r s e r ) S t e p h e n C. Johnson in L a n g u a g e D e v e l o p m e n t Tools o n the UNIX S y s t e m m a k e s points about t h e UNM philosophy of software tools relevant t o t h e building of Telecenter.

We feel t h e s e points a r e of i n t e r e s t h e r e , first, b e c a u s e T e l e c e n t e r incor- p o r a t e s U r n utilities a n d , second, b e c a u s e it has a highly m o d u l a r design.

Over t h e y e a r s , a n u m b e r of g e n e r a l utility p r o g r a m s have grown up o n t h e UNM s y s t e m . Many of t h e s e tools m a y b e viewed a s a n encapsulation of a piece of specialized knowledge-anything from driving a piece of hardware t o performing a utility t a s k .

(10)

They may be a s simple a s a s i n subroutine, or as complex a s a disk driver. By using tools. programmers a r e able t o gain access t o facilities and algorithms t h a t they do not have t o under- s t a n d in detail. Not surprisingly, constructing programs by using available tools and pieces has proved t o be very successful:

The resulting products a r e produced quickly.

They a r e likely t o work correctly.

They a r e often quite flexible a n d adaptable as applications change.

Inter-machine portability is often enhanced by using tools.

Tool usage encourages a natural modularity in the resulting program.

Using tools constructed by experts, programmers g e t t h e u s e of e x p e r t algorithms.

(Johnson, p. 16)

U N X h a s many utility programs written t o do simple things t o text files, like printing lines t h a t contain a specified p a t t e r n , eliminating duplicate lines in a sorted file, or printing t h e first o r last few lines of a file. All these simple "tools" a r e designed t o be flexibly combined a t t h e command level to perform more complex tasks, and t o use t h e m in this way requires no programming and little effort.

Most of t h e facilities for doing Telecenter's basic tasks already exist under UNIX in t h e fprm of utilities-for example, a simple screen- oriented editor program e d z for creating and modifying text, a utility called g r e p for searching files for strings of interest, t h e utility d a t e for inserting t h e d a t e and time into conference comment headers, notifica- tions of login and logout times, and so forth. They also s t r u c t u r e information (see t h e paragraph below on file system).

C o m m a n d interpreter

The command interpreter-called t h e "shell" in UNIX-is t h e pri- mary mechanism through which time-sharing users interact wit.h UNIX. A shell is a normal, un-priveleged user program t h a t typically r e a d s commands typed by t h e user a t his or her terminal and executes functions ei- t h e r through code compiled into t h e shell itself, by running o t h e r pro- g r a m s , o r by interpreting t e x t files containing shell commands. The shell used t o implement Telecenter is called the C shell a n d is t h e shell used by all UNIX u s e r s a t our institute (see Joy). For implementing Telecenter, t h e

*

For u s e r s with hardcopy termina1.s a line-oriented editor is optional.

(11)

C shell was used as a very high level, block s t r u c t u r e d , interpretive programming language which provided convenient access t o built-in functions, utilities and the various programming features of t h e C shell itself, including variables, simple numeric expressions, p a t t e r n matching, mac- ros and file system manipulation.

Except for one or two trivial compiled programs, all aspects of Telecenter a r e small (ideally thirty-five to seventy lines of code each) C- shell "programs" (sometimes called scripts) t h a t a r e easy t o write and modify. Since the basic elements of this "programming language" a r e normal interactive commands, sometimes parametarized and/or condi- tionalized. powerful functions using many utility programs combined in various ways can be implemented by users with little or no programming experience. Furthermore, since this language is interpretive, i t is easy t o debug and experiment with programs, or p a r t s of them, merely by typing t h e m interactively a t t h e terminal.

Transparency

Since t h e r e is g r e a t consistency between built-in functions, compiled programs and C-shell scripts, all can be combined within C-shell programs or m a d e directly available to the user without knowing or car- ing how a given function is implemented. This allows modules to b e easily replaced by more efficient implementations for efficiency reasons once t h e required functionality is well-known, presumably determined through a flexible, very high level, interpretive "first attempt".

In a first stage of development, where we a r e now, appropriate functionality &an be explored by user-oriented people able t o modify shell-scripts. In a second stage, efficiency can be achieved for those functions deemed desirable by having shell-scripts partially or wholly converted to either compiled programs or functions built into t h e shell.

In t h e meantime all components of t h e system a r e compatible with one another-all modules interconnect. We a r e confident about the second stage of Telecenter's evolution because UNIX supports a modern, struc- t u r e d programming language called "C" (see Kernighan and Ritchie) t h a t is superior t o FORTRAN and o t h e r earlier programming languages and offers the kind of access t o t h e operating system &hat has been shown t o be essential for developing these kinds of systems.

8

In a review of both hardware and software requirements for implementing computerized conferencing systems, Hiltz and Turoff have pointed out, "The c u r r e n t t r e n d toward insulating the higher-level languages frorn t h e operating system needs t o be reversed, so that the conference pro- g r a m in t h a t language can control t h e operating systems. This means t h a t t h e s t a t u s and control of interrupts and 1/0 have to be incorporated a t the higher level

..."

and t h a t "Most conference packages today have t o make frequent transitions into t h e domain of the operating system command language. All user 1/0 (break key, e t c . ) has to be removed from t h e operating system t o the conference system so t h e r e is no way for t h e u s e r t o g e t a t t h e operating system." (Hiltz and Turoff, pp. 390-1)

(12)

F i l e s y s t e m

The s t r u c t u r i n g of information in Telecenter was facilitated by t h e f a c t t h a t UNM h a s a simple y e t powerful file/directory s y s t e m t h a t s u p p o r t s t h e organization of files into a n arbitrarily d e e p hierarchy.

Every d i r e c t o r y c a n contain files and/or m o r e directories. A d i r e c t o r y e n t r y for a file (called a link) c a n b e placed in m o r e t h a n one d i r e c t o r y , t h u s allowing a file t o a p p e a r in m a n y directories a t once.

Organizing Telecenter u s e r s , conferences a n d c o n f e r e n c e parti- c i p a n t s was done simply b y writing C-shell s c r i p t s t h a t manipulate t h e ap- p r o p r i a t e directories-a d i r e c t o r y hierarchy for u s e r s a n d a d i r e c t o r y h i e r a r c h y for conferences. Thus when a participant s u b m i t s a conference c o m m e n t h e o r s h e does s o b y calling a function t h a t c r e a t e s and links files in a p p r o p r i a t e directories. The Telecenter functions t h a t do t h e s e things i n c o r p o r a t e s t a n d a r d UNiX utilities for making, linking, moving among, a n d removing d i r e c t o r i e s a s well a s t h o s e for making, linking, editing a n d removing files. F o r example, keeping t r a c k of who has s e e n what is simply a m a t t e r of establishing links for e a c h p a r t i c i p a n t t o a single c o m m e n t file, removing a link when someone h a s viewed a conference c o m m e n t a n d t h e n , for a n y given conference, counting who still h a s links a n d how many.

In effect, UNIX's directory/file s t r u c t u r e provides a simple d a t a - base m a n a g e m e n t s y s t e m for implementors a n d u s e r s of Telecenter.

The p h r a s e "think globallj., a c t locally" w a s t h e t h e m e of a r e - c e n t world f u t u r e s conference in Canada. I t s e e m s t o u s t h a t t h e s e words s u m m a r i z e well what we feel t o b e of value in t h e design a p p r o a c h t o t h e UNIX-based c o m p u t e r conferencing s y s t e m described above. By responding t o t h e n e e d s of a c t u a l u s e r s , we think t h a t we have c r e a t e d a useful collection of c o m m u n i c a t i o n s functions. By c r e a t i n g t h e m on t h e techni- cal basis of a s t a n d a r d , widely available and m o d e r n operating s y s t e m s u c h a s UNM, w e hope t h a t o u r a p p r o a c h will be of u s e t o a widel. commun- ity a s a small e x a m p l e of adaptive design in an e x p e r i m e n t a l b u t useful si- tuation.

(13)

(14)

REFERENCES

Garnbino, T.J. (1980) Irnpleinentation Resear.ch and DSS. P a p e r delivered by Gambino on work done t o g e t h e r with P e t e r Keen. Delivered at t h e 5 t h Annual InFormation S y s t e m s S u m m e r Workshop held in Williamstown, Mass.. U.S.A., whose t h e m e was S t r a t e g i e s for Supporting Management of t h e F u t u r e . (Quoted m a t e r i a l on t h e basis of notes p r e p a r e d by Alain Barbarie, Management and Technology Area, IIASA.)

Hiltz, S. R., and

M.

Turoff (1978) The Net7uork Nation. Addison-Wesley.

Johnson, S t e p h e n C. (1980) Language Development Tools on t h e Ul.1IX Sys- t e m . Computer. Vol. 13, No. 8, August, pp. 16-21.

Joy, William (1980) An introduction t o t h e C shell. Computer Science Divi- sion, Department of Electrical Engineering a n d Computer Sci- e n c e , University of California, Berkeley, Berkeley, Ca1iforni.a 94720.

Kernighan, B. W. and D. M. Ritchie (1978) The C Programming Language.

Prentice-Hall, Inc., Englewood Cliffs, New Jersey.

Miller, Richard (1980) Representing t h e Message S y s t e m User Environ- m e n t : A Report t o t h e User Environment Sub-Group, IFIP Work- ing Group 6.5. Contribution t o International Federation for 111- formation Processing workshop on c o m p u t e r message s y s t e m s held May, 1980 a t t h e Gesellschaft f u e r Mathematik u n d Daten- verarbeitung in Bonn, FRG, a n d organized by IFIP Working Group

(15)

6.5 on international computer message systems. Will be part of a forthcoming workshop proceedings.

Pearson, M.M.L. (1980a) U s i n g t h e C o m p z ~ t e r t o C o m m u n i c a t e : A n I n t r o - d u c t i o n t o C o m p u t e r i z e d C o n f e r e n c i n g WP-80-72. Laxenburg.

Austria: International Institute for Applied Systems Analysis.

Pearson,

M.M.L.

(1980b) U s i n g t h e C o m p u t e r t o C o m m u n i c a t e : A n I n t r o - d u c t i o n t o T e z t P r o c e s s i n g at IIASA-the e d x and n r o f f p r o g r a m s WP-80-111. Laxenburg, Austria: International Institute for Ap- plied Systems Analysis.

Pearson, M.M.L. and C.L. Lathrop (1980) U s i n g t h e C o m p u t e r t o C o n m u n i - c a t e : A U s e r ' s G u i d e t o T e l e c e n t e r WP-80-109. Laxenburg, Austria:

International Institute for Applied Systems Analysis.

Sprague. Ralph (1980) An Overview of Decision Support Systems. Contri- bution to Task Force meeting on decision support systems held a t the International Institute for Applied Systems Analysis (IIA- SA). Schloss Laxenburg, Laxenburg. Austria on June 23-25. 1980.

To be published as part of a IIASA Conference Proceedings.

Uhlig, R.P., D.J. Farber, and J.H. Bair (1979) T h e O f f i c e of t h e F u t u r e North-Holland Publishing Company.