BABYL OPTIONS: Version: 5 Labels:cold-fusion,imp,look,hellobaby,atnannounce,cs545list,bug,feature,ruleeditor,argos Note: This is the header of an rmail file. Note: If you are seeing it in rmail, Note: it means the file has no messages in it.  1, Summary-line: 17-Mar COMSAT@AI.AI.MIT.EDU #Msg of Tuesday, 14 March 1989 20:32-EST Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA01362; Fri, 17 Mar 89 20:23:03 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA16816; Fri, 17 Mar 89 20:23:26 EST Received: by CHARON.MIT.EDU (5.45/4.7) id AA01865; Fri, 17 Mar 89 20:22:50 EST Date: Fri, 17 Mar 89 20:25:20 EST From: Communications Satellite Subject: Msg of Tuesday, 14 March 1989 20:32-EST To: "rap@ATHENA.MIT.EDU"@ATHENA.MIT.EDU Message-Id: <558735.890317@AI.AI.MIT.EDU> *** EOOH *** Date: Fri, 17 Mar 89 20:25:20 EST From: Communications Satellite Subject: Msg of Tuesday, 14 March 1989 20:32-EST To: "rap@ATHENA.MIT.EDU"@ATHENA.MIT.EDU FAILED: RDZ at SCORE.STANFORD.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Received: from CHARON.MIT.EDU (TCP 2224000015) by AI.AI.MIT.EDU 14 Mar 89 20:32:05 EST Received: by CHARON.MIT.EDU (5.45/4.7) id AA12768; Tue, 14 Mar 89 19:34:00 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA13256; Tue, 14 Mar 89 19:30:39 EST Received: by CLEOPATRA.MIT.EDU (5.45/4.7) id AA08319; Tue, 14 Mar 89 19:29:58 EST Date: Tue, 14 Mar 89 19:29:58 EST Message-Id: <8903150029.AA08319@CLEOPATRA.MIT.EDU> To: athena@ATHENA.MIT.EDU Subject: xlock Does anybody know where the source for this is? __Rich Pito.  1, Summary-line: 21-Mar jbs@ATHENA.MIT.EDU #Usenet newsgroups available Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA27657; Tue, 21 Mar 89 03:04:38 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA02865; Tue, 21 Mar 89 02:58:13 EST Received: by MORPHEUS.MIT.EDU (5.45/4.7) id AA03586; Tue, 21 Mar 89 02:56:50 EST Date: Tue, 21 Mar 89 02:56:50 EST Message-Id: <8903210756.AA03586@MORPHEUS.MIT.EDU> To: alens@ATHENA.MIT.EDU Subject: Usenet newsgroups available *** EOOH *** From: Date: Tue, 21 Mar 89 02:56:50 EST To: alens@ATHENA.MIT.EDU Subject: Usenet newsgroups available This is the complete list of usenet newsgroups. Let me know if any appear to be of interest; I can arrange to make them available for anyone server selection. Jeff -- Newsgroup Description ---------------------------------------------------------------------- comp.ai Artificial intelligence discussions. comp.ai.digest Artificial Intelligence discussions. (Moderated) comp.ai.neural-nets All aspects of neural networks. comp.ai.nlang-know-rep Natural Language and Knowledge Representation. (Moderated) comp.arch Computer architecture. comp.archives Descriptions of public access archives. (Moderated) comp.binaries.amiga Encoded public domain programs in binary. (Moderated) comp.binaries.apple2 Binary-only postings for the Apple II computer. comp.binaries.atari.st Binary-only postings for the Atari ST. (Moderated) comp.binaries.ibm.pc Binary-only postings for IBM PC/MS-DOS. (Moderated) comp.binaries.ibm.pc.d Discussions about IBM/PC binary postings. comp.binaries.mac Encoded Macintosh programs in binary. (Moderated) comp.bugs.2bsd Reports of UNIX* version 2BSD related bugs. comp.bugs.4bsd Reports of UNIX version 4BSD related bugs. comp.bugs.4bsd.ucb-fixes Bug reports/fixes for BSD Unix. (Moderated) comp.bugs.misc General UNIX bug reports and fixes (incl V7, uucp) comp.bugs.sys5 Reports of USG (System III, V, etc.) bugs. comp.cog-eng Cognitive engineering. comp.compilers Compiler construction, theory, etc. (Moderated) comp.databases Database and data management issues and theory. comp.dcom.lans Local area network hardware and software. comp.dcom.modems Data communications hardware and software. comp.dcom.telecom Telecommunications digest. (Moderated) comp.doc Archived public-domain documentation. (Moderated) comp.doc.techreports Lists of technical reports. (Moderated) comp.edu Computer science education. comp.emacs EMACS editors of different flavors. comp.fonts Typefonts -- design, conversion, use, etc. comp.graphics Computer graphics, art, animation, image processing. comp.graphics.digest Graphics software, hardware, theory, etc. (Moderated) comp.ivideodisc Interactive videodiscs -- uses, potential, etc. comp.lang.ada Discussion about Ada*. comp.lang.apl Discussion about APL. comp.lang.c Discussion about C. comp.lang.c++ The object-oriented C++ language. comp.lang.eiffel The object-oriented Eiffel language. comp.lang.forth Discussion about Forth. comp.lang.fortran Discussion about FORTRAN. comp.lang.lisp Discussion about LISP. comp.lang.misc Different computer languages not specifically listed. comp.lang.modula2 Discussion about Modula-2. comp.lang.pascal Discussion about Pascal. comp.lang.postscript The PostScript Page Description Language. comp.lang.prolog Discussion about PROLOG. comp.lang.scheme The Scheme Programming language. comp.lang.sigplan Info & announcements from ACM SIGPLAN. (Moderated) comp.lang.smalltalk Discussion about Smalltalk 80. comp.laser-printers Laser printers, hardware & software. (Moderated) comp.lsi Large scale integrated circuits. comp.mail.elm Discussion and fixes for ELM mail system. comp.mail.headers Gatewayed from the ARPA header-people list. comp.mail.maps Various maps, including UUCP maps. (Moderated) comp.mail.mh The UCI version of the Rand Message Handling system. comp.mail.misc General discussions about computer mail. comp.mail.sendmail Configuring and using the BSD sendmail agent. comp.mail.uucp Mail in the uucp network environment. comp.misc General topics about computers not covered elsewhere. comp.newprod Announcements of new products of interest. (Moderated) comp.org.decus DEC* Users' Society newsgroup. comp.org.fidonet FidoNews digest, official news of FidoNet Assoc. (Moderated) comp.org.ieee Issues and announcements about the IEEE & its members. comp.org.usenix USENIX Association events and announcements. comp.org.usrgroup News/discussion about/from the /usr/group organization. comp.os.cpm Discussion about the CP/M operating system. comp.os.eunice The SRI Eunice system. comp.os.minix Discussion of Tanenbaum's MINIX system. comp.os.misc General OS-oriented discussion not carried elsewhere. comp.os.os9 Discussions about the os9 operating system. comp.os.research Operating systems and related areas. (Moderated) comp.os.vms DEC's VAX* line of computers & VMS. comp.os.xinu The XINU operating system from Purdue (D. Comer). comp.parallel Massively parallel hardware/software. (Moderated) comp.periphs Peripheral devices. comp.protocols.appletalk Applebus hardware & software. comp.protocols.ibm Networking with IBM mainframes. comp.protocols.iso The ISO protocol stack. comp.protocols.kermit Info about the Kermit package. (Moderated) comp.protocols.misc Various forms and types of FTP protocol. comp.protocols.nfs Discussion about the Network File System protocol. comp.protocols.tcp-ip TCP and IP network protocols. comp.protocols.tcp-ip.ibmpc TCP/IP for IBM(-like) personal computers. comp.risks Risks to the public from computers & users. (Moderated) comp.simulation Simulation methods, problems, uses. (Moderated) comp.society The impact of technology on society. (Moderated) comp.society.futures Events in technology affecting future computing. comp.society.women Women's roles and problems in computing (Moderated) comp.software-eng Software Engineering and related topics. comp.sources.amiga Source code-only postings for the Amiga. (Moderated) comp.sources.atari.st Source code-only postings for the Atari ST. (Moderated) comp.sources.bugs Bug reports, fixes, discussion for posted sources comp.sources.d For any discussion of source postings. comp.sources.games Postings of recreational software. (Moderated) comp.sources.games.bugs Bug reports and fixes for posted game software. comp.sources.mac Software for the Apple Macintosh. (Moderated) comp.sources.misc Posting of software . (Moderated) comp.sources.unix Postings of complete, UNIX-oriented sources. (Moderated) comp.sources.wanted Requests for software and fixes. comp.sources.x Software for the X windows system. (Moderated) comp.std.c Discussion about C language standards. comp.std.internat Discussion about international standards. comp.std.misc Discussion about various standards. comp.std.mumps Discussion for the X11.1 committee on Mumps. (Moderated) comp.std.unix Discussion for the P1003 committee on UNIX. (Moderated) comp.sys.amiga Commodore Amiga: info&uses, but no programs. comp.sys.amiga.tech Technical discussion about the Amiga. comp.sys.apollo Apollo computer systems. comp.sys.apple Discussion about Apple micros. comp.sys.atari.8bit Discussion about 8 bit Atari micros. comp.sys.atari.st Discussion about 16 bit Atari micros. comp.sys.att Discussions about AT&T microcomputers. comp.sys.cbm Discussion about Commodore micros. comp.sys.celerity Celerity Computers comp.sys.dec Discussions about DEC computer systems. comp.sys.dec.micro DEC Micros (Rainbow, Professional 350/380) comp.sys.encore Encore's MultiMax computers. comp.sys.hp Discussion about Hewlett-Packard equipment. comp.sys.ibm.pc Discussion about IBM personal computers. comp.sys.ibm.pc.digest The IBM PC, PC-XT, and PC-AT. (Moderated) comp.sys.ibm.pc.rt Topics related to IBM's RT computer. comp.sys.intel Discussions about Intel systems and parts. comp.sys.m6809 Discussion about 6809's. comp.sys.m68k Discussion about 68k's. comp.sys.m68k.pc Discussion about 68k-based PCs. (Moderated) comp.sys.mac Discussions about the Apple Macintosh & Lisa. comp.sys.mac.digest Apple Macintosh: info&uses, but no programs. (Moderated) comp.sys.mac.hypercard The Macintosh Hypercard: info & uses. comp.sys.mac.programmer Discussion by people programming the Apple Macintosh. comp.sys.masscomp The Masscomp line of computers. (Moderated) comp.sys.misc Discussion about computers of all kinds. comp.sys.next Discussion about the new NeXT computer. comp.sys.nsc.32k National Semiconductor 32000 series chips. comp.sys.proteon Proteon gateway products. comp.sys.pyramid Pyramid 90x computers. comp.sys.ridge Ridge 32 computers and ROS. comp.sys.sequent Sequent systems, (Balance and Symmetry). comp.sys.sgi Silicon Graphics's Iris workstations and software. comp.sys.sun Sun "workstation" computers. (Moderated) comp.sys.tahoe CCI 6/32, Harris HCX/7, & Sperry 7000 computers. comp.sys.tandy Discussion about TRS-80's. comp.sys.ti Discussion about Texas Instruments. comp.sys.transputer The Transputer computer and OCCAM language. comp.sys.workstations Various workstation-type computers. (Moderated) comp.sys.xerox Xerox 1100 workstations and protocols. comp.sys.zenith.z100 The Zenith Z-100 (Heath H-100) family of computers. comp.terminals All sorts of terminals. comp.text Text processing issues and methods. comp.text.desktop Technology & techniques of desktop publishing. comp.theory.info-retrieval Information Retrieval topics. (Moderated) comp.unix Discussion of UNIX* features and bugs. (Moderated) comp.unix.aux The version of UNIX for Apple Macintosh II computers. comp.unix.i386 Versions of Unix running on Intel 80386-based boxes. comp.unix.microport Discussion of Microport's UNIX. comp.unix.questions UNIX neophytes group. comp.unix.ultrix Discussions about DEC's Ultrix. (Moderated) comp.unix.wizards Discussions, bug reports, and fixes on and for UNIX. comp.unix.xenix Discussion about the Xenix OS. comp.windows.misc Various issues about windowing systems. comp.windows.ms Window systems under MS/DOS. comp.windows.news Sun Microsystems' NewS window system. comp.windows.x Discussion about the X Window System. misc.consumers Consumer interests, product reviews, etc. misc.consumers.house Discussion about owning and maintaining a house. misc.forsale Short, tasteful postings about items for sale. misc.handicap Items of interest for/about the handicapped. (Moderated) misc.headlines Current interest: drug testing, terrorism, etc. misc.invest Investments and the handling of money. misc.jobs.misc Discussion about employment, workplaces, careers. misc.jobs.offered Announcements of positions available. misc.jobs.resumes Postings of resumes and "situation wanted" articles. misc.kids Children, their behavior and activities. misc.legal Legalities and the ethics of law. misc.misc Various discussions not fitting in any other group. misc.security Security in general, not just computers. (Moderated) misc.taxes Tax laws and advice. misc.test For testing of network software. Very boring. misc.wanted Requests for things that are needed (NOT software). news.admin Comments directed to news administrators. news.announce.conferences Calls for papers and conference announcements. (Moderated) news.announce.important General announcements of interest to all. (Moderated) news.announce.newusers Explanatory postings for new users. (Moderated) news.config Postings of system down times and interruptions. news.groups Discussions and lists of newsgroups. news.lists News-related statistics and lists. (Moderated) news.misc Discussions of USENET itself. news.newsites Postings of new site announcements. news.software.b Discussion about B-news-compatible software. news.software.notes Notesfile software from the Univ. of Illinois. news.sysadmin Comments directed to system administrators. rec.arts.anime Japanese animation fen discussion. rec.arts.books Books of all genres, and the publishing industry. rec.arts.comics Comic books and strips, graphic novels, sequential art. rec.arts.drwho Discussion about Dr. Who. rec.arts.int-fiction Discussions about interactive fiction. rec.arts.misc Discussions about the arts not in other groups. rec.arts.movies Discussions of movies and movie making. rec.arts.movies.reviews Reviews of movies. (Moderated) rec.arts.poems For the posting of poems. rec.arts.sf-lovers Science fiction lovers' newsgroup. rec.arts.startrek Star Trek, the TV shows and the movies. rec.arts.tv The boob tube, its history, and past and current shows. rec.arts.tv.soaps Postings about soap operas. rec.arts.wobegon "A Prairie Home Companion" radio show discussion. rec.audio High fidelity audio. rec.autos Automobiles, automotive products and laws. rec.autos.sport Discussion of organized, legal auto competitions. rec.autos.tech Technical aspects of automobiles, et. al. rec.aviation Aviation rules, means, and methods. rec.backcountry Activities in the Great Outdoors. rec.bicycles Bicycles, related products and laws. rec.birds Hobbyists interested in bird watching. rec.boats Hobbyists interested in boating. rec.equestrian Discussion of things equestrian. rec.folk-dancing Folk dances, dancers, and dancing. rec.food.cooking Food, cooking, cookbooks, and recipes. rec.food.drink Wines and spirits. rec.food.veg Vegetarians. rec.games.board Discussion and hints on board games. rec.games.bridge Hobbyists interested in bridge. rec.games.chess Chess & computer chess. rec.games.empire Discussion and hints about Empire. rec.games.frp Discussion about Fantasy Role Playing games. rec.games.go Discussion about Go. rec.games.hack Discussion, hints, etc. about the Hack game. rec.games.misc Games and computer games. rec.games.moria Comments, hints, and info about the Moria game. rec.games.pbm Discussion about Play by Mail games. rec.games.programmer Discussion of adventure game programming. rec.games.rogue Discussion and hints about Rogue. rec.games.trivia Discussion about trivia. rec.games.video Discussion about video games. rec.gardens Gardening, methods and results. rec.guns Discussions about firearms. (Moderated) rec.ham-radio Amateur Radio practices, contests, events, rules, etc. rec.ham-radio.packet Discussion about packet radio setups. rec.humor Jokes and the like. May be somewhat offensive. rec.humor.d Discussions on the content of rec.humor articles. rec.humor.funny Jokes that are funny (in the moderator's opinion). (Moderated) rec.mag Magazine summaries, tables of contents, etc. rec.mag.otherrealms Edited science fiction & fantasy "magazine". (Moderated) rec.misc General topics about recreational/participant sports. rec.models.rc Radio-controlled models for hobbyists. rec.motorcycles Motorcycles and related products and laws. rec.music.beatles Postings about the Fab Four & their music. rec.music.bluenote Discussion of jazz, blues, and related types of music. rec.music.cd CDs -- availability and other discussions. rec.music.classical Discussion about classical music. rec.music.dementia Discussion of comedy and novelty music. rec.music.folk Folks discussing folk music of various sorts. rec.music.gaffa Progressive music (e.g., Kate Bush). (Moderated) rec.music.gdead A group for (Grateful) Dead-heads. rec.music.makers For performers and their discussions. rec.music.misc Music lovers' group. rec.music.synth Synthesizers and computer music. rec.nude Hobbyists interested in naturist/nudist activities. rec.pets Pets, pet care, and household animals in general. rec.photo Hobbyists interested in photography. rec.puzzles Puzzles, problems, and quizzes. rec.railroad Real and model train fans' newsgroup. rec.scuba Hobbyists interested in SCUBA diving. rec.skiing Hobbyists interested in skiing. rec.skydiving Hobbyists interested in skydiving. rec.sport.baseball Discussion about baseball. rec.sport.basketball Discussion about basketball. rec.sport.football Discussion about football. rec.sport.hockey Discussion about hockey. rec.sport.misc Spectator sports. rec.travel Traveling all over the world. rec.video Video and video components. rec.woodworking Hobbyists interested in woodworking. sci.astro Astronomy discussions and information. sci.bio Biology and related sciences. sci.crypt Different methods of data en/decryption. sci.electronics Circuits, theory, electrons and discussions. sci.environment Discussions about the environment and ecology. sci.lang Natural languages, communication, etc. sci.lang.japan The Japanese language, both spoken and written. sci.logic Logic -- math, philosophy & computational aspects. sci.math Mathematical discussions and pursuits. sci.math.stat Statistics discussion. sci.math.symbolic Symbolic algebra discussion. sci.med Medicine and its related products and regulations. sci.med.aids AIDS: treatment, pathology/biology of HIV, prevention. (Moderated) sci.military Discussion about science & the military. (Moderated) sci.misc Short-lived discussions on subjects in the sciences. sci.nanotech Self-reproducing molecular-scale machines. (Moderated) sci.philosophy.tech Technical philosophy: math, science, logic, etc. sci.physics Physical laws, properties, etc. sci.psychology Topics related to psychology. sci.research Research methods, funding, ethics, and whatever. sci.space Space, space programs, space related research, etc. sci.space.shuttle The space shuttle and the STS program. soc.college College, college activities, campus life, etc. soc.couples Discussions for couples (cf. soc.singles). soc.culture.african Discussions about Africa & things African. soc.culture.arabic Technological & cultural issues, *not* politics. soc.culture.china About China and Chinese culture. soc.culture.celtic Group about Celts (*not* basketball!). soc.culture.greek Group about Greeks. soc.culture.indian Group for discussion about India & things Indian. soc.culture.japan Everything Japanese, except the Japanese language. soc.culture.jewish Jewish culture & religion. (cf. talk.politics.mideast) soc.culture.misc Group for discussion about other cultures. soc.culture.turkish Discussion about things Turkish. soc.human-nets Computer aided communications digest. (Moderated) soc.men Issues related to men, their problems & relationships. soc.misc Socially-oriented topics not in other groups. soc.motss Issues pertaining to homosexuality. soc.net-people Announcements, requests, etc. about people on the net. soc.politics Political problems, systems, solutions. (Moderated) soc.politics.arms-d Arms discussion digest. (Moderated) soc.religion.christian Christianity and related topics. (Moderated) soc.roots Genealogical matters. soc.singles Newsgroup for single people, their activities, etc. soc.women Issues related to women, their problems & relationships. talk.abortion All sorts of discussions and arguments on abortion. talk.bizarre The unusual, bizarre, curious, and often stupid. talk.origins Evolution versus creationism (sometimes hot!). talk.philosophy.misc Philosophical musings on all topics. talk.politics.mideast Discussion & debate over Middle Eastern events. talk.politics.misc Political discussions and ravings of all kinds. talk.politics.soviet Discussion of Soviet politics, domestic and foreign. talk.politics.theory Theory of politics and political systems. talk.religion.misc Religious, ethical, & moral implications. talk.religion.newage Esoteric and minority religions & philosophies. talk.rumors For the posting of rumors. -------------------- * UNIX is a registered Trademark of AT&T. * DEC and Ultrix are Trademarks of the Digital Equipment Corporation. * VAX is a Trademark of the Digital Equipment Corporation. * Ada is a registered Trademark of the Ada Joint Program Office of the United States Department of Defense.  1, Summary-line: 4-Apr ristopher%greube.DEC@decw #RE: Opportunities at DEC Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA12774; Tue, 4 Apr 89 12:52:19 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA07783; Tue, 4 Apr 89 13:52:12 EDT Received: by decwrl.dec.com (5.54.5/4.7.34) id AA19059; Tue, 4 Apr 89 10:52:54 PDT Date: Tue, 4 Apr 89 10:52:54 PDT Message-Id: <8904041752.AA19059@decwrl.dec.com> Received: by decwrl.dec.com (5.54.5/4.7.34) for rap@athena.mit.edu; id AA19059; Tue, 4 Apr 89 10:52:54 PDT From: christopher%greube.DEC@decwrl.dec.com (ZKO3-2/XI6, DTN: 381-0747) To: rap@ATHENA.MIT.EDU Subject: RE: Opportunities at DEC *** EOOH *** Date: Tue, 4 Apr 89 10:52:54 PDT From: christopher%greube.DEC@decwrl.dec.com (ZKO3-2/XI6, DTN: 381-0747) To: rap@ATHENA.MIT.EDU Subject: RE: Opportunities at DEC Hi, Mid May sounds fine. I will be taking a few days of vacation around the 10th, so it would be better if we could get together the week after May 10th. Why don't you get in touch with me in early May and we'll make arrangements to meet the week of May 15th. I'm looking forward to meeting you! - Debbie.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA00775; Sat, 15 Apr 89 01:12:04 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08027; Sat, 15 Apr 89 02:10:49 EDT Received: by FLOTSAM.MIT.EDU (5.45/4.8) id AA00581; Sat, 15 Apr 89 02:10:13 EDT From: Daniel I. Applebaum Message-Id: <8904150610.AA00581@FLOTSAM.MIT.EDU> To: video-mail@ATHENA.MIT.EDU Subject: Explanation, not apology Date: Sat, 15 Apr 89 01:10:11 EST *** EOOH *** From: Daniel I. Applebaum To: video-mail@ATHENA.MIT.EDU Subject: Explanation, not apology Date: Sat, 15 Apr 89 01:10:11 EST I seem to have screwed up flotsam's mail handler for the previous 24 hours or so, so I was not aware of Don's or Brian's last few mail messages before yesterday's meeting. Therefore, at the meeting, when Brian referenced his mail about the scheduler, the only reference I drew was about his first mail message with the simple sketch of the functions. I have now received several back-ordered messages, so I should be up-to-date. "Gee, why aren't I getting any mail? Doesn't anybody like me anymore?" Dan.  1,answered,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA11534; Sat, 15 Apr 89 15:24:09 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA14936; Sat, 15 Apr 89 16:24:35 EDT Received: from BUCSD.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA00432; Sat, 15 Apr 89 16:18:30 EDT Received: by bucsd.bu.edu (5.31/4.7) id AA06556; Sat, 15 Apr 89 15:26:15 EST Date: Sat, 15 Apr 89 15:26:15 EST From: jbf@bu-cs.BU.EDU Message-Id: <8904152026.AA06556@bucsd.bu.edu> To: rap@ATHENA.MIT.EDU, rap%bucsf.BU.EDU@bu-it.bu.edu Subject: MUCH MUCH improved *** EOOH *** Date: Sat, 15 Apr 89 15:26:15 EST From: jbf@bu-cs.BU.EDU To: rap@ATHENA.MIT.EDU, rap%bucsf.BU.EDU@bu-it.bu.edu Subject: MUCH MUCH improved The draft of 4-14-89 is much much better. The main remaining difficulty is its incompleteness. How is the program coming? Most of my comments are minor, so there need be no rush to pick up my copy. But I will likely be over on Monday, if only to catch a glimpse of the Marathon. If you want it before then, or if you have Section 3. Conclusions, things can be picked up and left off at the desk in my condo, near Harvard Square. Let me know.  1,answered,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA01593; Sun, 16 Apr 89 15:26:09 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA26932; Sun, 16 Apr 89 16:26:39 EDT Received: by MORPHEUS.MIT.EDU (5.45/4.7) id AA13211; Sun, 16 Apr 89 16:23:36 EDT Date: Sun, 16 Apr 89 16:23:36 EDT Message-Id: <8904162023.AA13211@MORPHEUS.MIT.EDU> To: rap@ATHENA.MIT.EDU *** EOOH *** From: Date: Sun, 16 Apr 89 16:23:36 EDT To: rap@ATHENA.MIT.EDU Please send $500 as soon as possible (Monday morning, preferably) by the interbank electronic funds transfer system. The destination is: BayBank Harvard Trust Co, Cambridge, MA Credit to Jeffrey Siegal, Account 99434391 Please reply when you read this Jeff  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA02079; Sun, 16 Apr 89 15:51:51 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA27276; Sun, 16 Apr 89 16:52:19 EDT Received: by MORPHEUS.MIT.EDU (5.45/4.7) id AA13377; Sun, 16 Apr 89 16:49:10 EDT Date: Sun, 16 Apr 89 16:49:10 EDT Message-Id: <8904162049.AA13377@MORPHEUS.MIT.EDU> To: rap@ATHENA.MIT.EDU In-Reply-To: 's message of Sun, 16 Apr 89 16:27:45 EDT <8904162027.AA01264@E40-334-3.MIT.EDU> *** EOOH *** From: Date: Sun, 16 Apr 89 16:49:10 EDT To: rap@ATHENA.MIT.EDU In-Reply-To: 's message of Sun, 16 Apr 89 16:27:45 EDT <8904162027.AA01264@E40-334-3.MIT.EDU> Bank closing is optional (it is only a state holiday, not federal). See if your bank is open. If not, please let me know and (obviously) wait until Tuesday. Jeff  1,,cold-fusion, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17664; Mon, 17 Apr 89 11:31:32 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA07977; Mon, 17 Apr 89 12:32:02 EDT Received: by MORPHEUS.MIT.EDU (5.45/4.7) id AA21498; Mon, 17 Apr 89 12:28:51 EDT Date: Mon, 17 Apr 89 12:28:51 EDT Message-Id: <8904171628.AA21498@MORPHEUS.MIT.EDU> To: rap@ATHENA.MIT.EDU In-Reply-To: 's message of Mon, 17 Apr 89 12:00:13 EDT <8904171600.AA01529@E40-334-3.MIT.EDU> *** EOOH *** From: Date: Mon, 17 Apr 89 12:28:51 EDT To: rap@ATHENA.MIT.EDU In-Reply-To: 's message of Mon, 17 Apr 89 12:00:13 EDT <8904171600.AA01529@E40-334-3.MIT.EDU> The whole world is a mess of red tape. The broker lost the signature form that I faxed, so I had to fax it again, wasting a half a day. Hopefully, we'll take our first position this afternoon. Otherwise tomorrow. In the news: Details about Prof. Hagelstein's cold fusion theory are leaking out and it looks promising. It appears that he explains how deuterium can be fused into helium rather than tritium (insufficient quantities of tritium has been one of the questions about the reaction). Prof. Hagelstein was the inventor of the X-ray laser (for the SDI project) at Los Alamos before being hired by MIT. Palladium prices have been steady since last week's climb (about $20/ounce). The increased spread I talked about appeared during this climb as it has in the past, and I'm waiting to see if it closes soon, as expected. I'll keep in touch. By the way, please don't distribute the information that I give you. And, of course, let me know if you see or hear anything interesting. Jeff  1,answered,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA19039; Tue, 18 Apr 89 17:50:38 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA04020; Tue, 18 Apr 89 18:49:04 EDT Received: by PINK.MIT.EDU (5.45/4.7) id AA04232; Tue, 18 Apr 89 18:48:40 EDT Date: Tue, 18 Apr 89 18:48:40 EDT Message-Id: <8904182248.AA04232@PINK.MIT.EDU> To: alens@ATHENA.MIT.EDU Subject: possible problem in move-to *** EOOH *** From: Date: Tue, 18 Apr 89 18:48:40 EDT To: alens@ATHENA.MIT.EDU Subject: possible problem in move-to Consider a likely set of rules: IF To: %contains alens Then move-to alens-folder IF From: %contains rap Then move-to alens-folder IF From: %contains jbs then move-to alens-folder My question is this: Does one or two copies of the message to alens from rap appear in my alens-folder after a runrules ? My guess is that two copies appear there. My other question is: Is there a way to alter rule #2 such that it will not wrongly fire on a message from someone else, such as "strap@bucsf" ? To the first question, I would expect that only one copy of the message should appear in alens-folder afterwards. (Note that this is not a "move-to" problem, such as we'd discussed earlier. If the second rule had "move-to from-rap", I would be quite happy to find the message in both the alens-folder and from-rap folder afterwards.) This problem is more like the folder-registry problem we've discussed to keep track of what folders where already open. Perhaps the folder registry could also check if the message about to be moved to an open folder, is already in the folder. This also relates to a possible infinite-loop bug in the Lens design. If a message is moved *to* the same folder it is being moved *from*, then currently this *may* (or may not) cause an infinite-loop. (I same *may* because the design doesn't specify the outcome, nor does the actual code. The loop may occur depending on whether you're using a nested ruleset, which mailer you use, or the pseudo-random way that Unix places the files onto a physical disk.) -- Brian  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA21212; Tue, 18 Apr 89 19:29:00 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA05560; Tue, 18 Apr 89 20:26:56 EDT Received: by E40-334-3.MIT.EDU (5.45/4.7) id AA02006; Tue, 18 Apr 89 20:26:47 EDT Date: Tue, 18 Apr 89 20:26:47 EDT Message-Id: <8904190026.AA02006@E40-334-3.MIT.EDU> To: bgardner@ATHENA.MIT.EDU Cc: alens@ATHENA.MIT.EDU In-Reply-To: 's message of Tue, 18 Apr 89 18:48:40 EDT <8904182248.AA04232@PINK.MIT.EDU> Subject: possible problem in move-to *** EOOH *** From: Date: Tue, 18 Apr 89 20:26:47 EDT To: bgardner@ATHENA.MIT.EDU Cc: alens@ATHENA.MIT.EDU In-Reply-To: 's message of Tue, 18 Apr 89 18:48:40 EDT <8904182248.AA04232@PINK.MIT.EDU> Subject: possible problem in move-to From: Date: Tue, 18 Apr 89 18:48:40 EDT Consider a likely set of rules: IF To: %contains alens Then move-to alens-folder IF From: %contains rap Then move-to alens-folder IF From: %contains jbs then move-to alens-folder My question is this: Does one or two copies of the message to alens from rap appear in my alens-folder after a runrules ? My guess is that two copies appear there. My other question is: Is there a way to alter rule #2 such that it will not wrongly fire on a message from someone else, such as "strap@bucsf" ? To the first question I would didagree that only one copy of the mesage be placed in alens-folder. The ruleset says to put two copies there, and this is a source of information for the user. When two copies appear, it tells the user that two rules have fired on this message:in essence saying there are two paths for this message to this folder. If we cut one path out because it is redundant we introduce 2 problems (1) the user does not know which rule sent it there (2) the user will be confronted again with the problem of order of rules within rulesets (i.e. he would think that the first rule actually moved the message so the other two couldn't act on it--this is not how we designed the system and to introduce an exception to Argos's flow of control within rulesets would introduce confusion.) Although it would be nice to have one copy of the message in alens-folder it is outguesing the user and hiding information about the message from him. To the second question the answer is a field type operator which recognixes word boundaries, maybe 'contains-as-word'. To the infinite loop questions raisded, yes, I agree that the only real place to guard against this is in a registry of folders which would not only revognize the autonomy of a folder but also of a ruleset. That is, it would have to recognize an execution of runrules on a particular invocation of a ruleset. I don't have time to answer all these questions but consider for rulesets R1, R2 and folders F1 and F2. R1 reads m1 from F1 and *moves* it to F1 This is legit, a move-to appends a message, this could be crucial in a ruleset that does reordering. R1 reads m1 from F1 and *moves* it to F1 as m10 Registry of folders marks m10 as a result of R1 R1 attempts to read m10 from F1, but fails because m10 is a result of R1 O.K. R1 reads m1 from F1 and *moves* it to F1 as m10 Registry of folders marks m10 as a result of R1 R1 invokes R2 R2 invokes R1 R1 attempts to read m10 from F1 what happens now? I contend that the second invocation of R1 is distinct from the first and it should be allowed to read m10. My reasoning is that this example illustrates a more 'derranged' form of the infinit-loop problem which Argos should not be designed to catch. Yet, why should R1 be allowed to again process m10? The answer is that it could be possible that R2 has altered the state of m10 so that as far as R1 is concerned it is not the same message. Therefore, the granularity of rulesets as far as the registry of folders is concerned should be at the invocation of ruleset level wrather than at the ruleset name level. Anyway, this is all in the future... __Rich.  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA24496; Tue, 18 Apr 89 21:59:07 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA07878; Tue, 18 Apr 89 22:57:29 EDT Received: by E40-368-1.MIT.EDU (5.45/4.7) id AA20460; Tue, 18 Apr 89 22:55:36 EDT Message-Id: <8904190255.AA20460@E40-368-1.MIT.EDU> To: alens@ATHENA.MIT.EDU Subject: Motif Date: Tue, 18 Apr 89 22:55:33 EDT Attached is Dave Flanagan's note on the status of Motif. Looks like we should try it on Wednesday... Wendy ------ From: Date: Fri, 14 Apr 89 15:34:15 EDT To: In-Reply-To: Wendy E. Mackay's message of Fri, 14 Apr 89 15:22:38 EDT, Subject: Re: motif docs now available The motif locker is `motifdev'. It contains {vax,rt}bin and {vax,rt}lib. The window manager and the widget libraries are there. vaxbin also contains the executables for a few very simple test programs for the widgets. The UIL compiler is not there because it does not build yet. I advise against trying anything with the widget library yet. We should get a new tape on Monday, and hopefully have it installed on tuesday. The new tape represents about a month of progress by OSF, and should be more robust. David Flanagan  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25044; Tue, 18 Apr 89 22:24:46 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08330; Tue, 18 Apr 89 23:23:08 EDT Received: by MORPHEUS.MIT.EDU (5.45/4.7) id AA28206; Tue, 18 Apr 89 23:20:19 EDT Date: Tue, 18 Apr 89 23:20:19 EDT Message-Id: <8904190320.AA28206@MORPHEUS.MIT.EDU> To: bgardner@ATHENA.MIT.EDU Cc: alens@ATHENA.MIT.EDU In-Reply-To: 's message of Tue, 18 Apr 89 18:48:40 EDT <8904182248.AA04232@PINK.MIT.EDU> Subject: possible problem in move-to In answer to the second question, there is a %contains_word operator for the Text fieldtypes. The default operator of the "mailbox" field type should handle this, but it doesn't work well enough to install into lens yet (perhaps I'll start working on improving it soon) Jeff  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25089; Tue, 18 Apr 89 22:26:28 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08350; Tue, 18 Apr 89 23:24:47 EDT Received: by MORPHEUS.MIT.EDU (5.45/4.7) id AA28221; Tue, 18 Apr 89 23:21:59 EDT Date: Tue, 18 Apr 89 23:21:59 EDT Message-Id: <8904190321.AA28221@MORPHEUS.MIT.EDU> To: mackay@ATHENA.MIT.EDU Cc: alens@ATHENA.MIT.EDU In-Reply-To: 's message of Tue, 18 Apr 89 22:55:33 EDT <8904190255.AA20460@E40-368-1.MIT.EDU> Subject: Motif The UIL compiler, is I think, key to the benefits we want to get from Motif. But I can start playing with the widget libraries (I'll let "alens" know how it is going) Jeff  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA26057; Tue, 18 Apr 89 23:16:29 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08933; Wed, 19 Apr 89 00:16:18 EDT Received: by PINK.MIT.EDU (5.45/4.7) id AA04592; Wed, 19 Apr 89 00:15:51 EDT Date: Wed, 19 Apr 89 00:15:51 EDT Message-Id: <8904190415.AA04592@PINK.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: multiple moves to the same folder Cc: alens@ATHENA.MIT.EDU Rich what you said about multiply moving a message to a folder as legit...is sort of true. Sort of, because it would be true if we had an "OR" operator in the ruleeditor. Unfortunately, since there isn't an OR operator, a user can only impliment an OR currently by writting several rules to effect the same action, but using different predicates. The 3 rules that I gave in my last example are, in fact, my own rule from my most used ruleset. I created those rules with the intent of moving only one copy of the message to the alens folder. I did NOT intend to have multiple copies of the message. I intended only one copy to be moved, the multiple rules to accomplish this were necessary to achieve the OR feature that I really wanted to use, but wasn't available. -- Brian  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA27006; Wed, 19 Apr 89 00:13:07 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA09648; Wed, 19 Apr 89 01:12:53 EDT Received: by PINK.MIT.EDU (5.45/4.7) id AA04611; Wed, 19 Apr 89 01:12:24 EDT Date: Wed, 19 Apr 89 01:12:24 EDT Message-Id: <8904190512.AA04611@PINK.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: Re: rap's response to multiple rules and multiple moves to the same folder. Cc: alens@ATHENA.MIT.EDU >The ruleset says to put two copies there, and this >is a source of information for the user. When two copies appear, it tells >the user that two rules have fired on this message:in essence saying there >are two paths for this message to this folder. If we cut one path out >because it is redundant we introduce 2 problems (1) the user does not know >which rule sent it there (2) the user will be confronted again with the >problem of order of rules within rulesets (i.e. he would think that the >first rule actually moved the message so the other two couldn't act on >it--this is not how we designed the system and to introduce an exc >Argos's flow of control within rulesets would introduce confusion.) (1) Because of the lack of an "OR" in the ruleeditor, the user will probably have multiple rules which attempt to do a SINGLE move of one message (even if several of these fire) into the same folder. (2) When two copies appear, it tells the user nothing. We don't have any mechanism today for automatically recognizing if there are duplicate messages in the same folder. (3) This unseen multiplication of messages is likely to be a very real problem with a user's disk quotas (whether via disk space wastage or over shooting the total # of files allowed). The worse part is that a user won't even know that this is a contributing cause of disk-quota problems, or how to delete the duplicates. (Since there is currently no way to recognize duplicates, its not possible to write a rule to open a folder and throw away the duplicates.) (4) The user does not know which rule(s) fired on the message anyway. (I response to your point (1). ) (5) Since the user doesn't know which rule(s) moved the message from the first folder (in my example "inbox") to the destination folder (in my example "alens-folder"), then all of the "path" "paths" to which you refer will look identical to the user in either of the implimentations. (i.e - since rule firings aren't stored with the message, then it is NOT the case that: F1 -> R1 -> F2 (rule 1 move msg from folder1 to folder2) F1 -> R2 -> F3 ^- Ooops that should be F2 etc.... The R1, R2, Rn isn't part of the msgs move path that's stored. What the user actually has for a post-mortem path on a msg doubly moved to the same folder, is more like: F1 -> R? -> F2 F1 -> R? -> F2 etc .... So, the double move gave the user no extra info, just extra disk usage. (*If* the user had "state-save" turned on, which isn't the default, then the user can tell how many rules fired on the message; so the 2 copies under these circumstances aren't exact copies. Likewise, if a permanent user property was set. If neither of these were true, which is often the case in my OR style multiple rules, then I simply get multiple indentical copies of the same message in the same folder, with no distinguishing information of the variety you were implying.) (6) Since the user never knows which rule set a particular message to a particular folder, your point (2) is also irrelevant. The user will not loose or gain any confusion about rule ordering in the case of moving identical copies of a message to the same destination folder. (7) In MH currently, if a message is moved to the same folder it came from, then it is in the actively open folder and may be fired upon again. It is quite possible for the message (after the move into the input folder) to be identical to the original message (before the move) and therefore would re-trigger the same rule. Since there are no folder-properties for intermessage communication, then it allowing a message to be moved into the input folder (if state-save is off and no user properties were permenant) would NECESSARILY impose an infinite loop; and the messaage would continue to leap-frog within the same folder indefinately. (Its possible that a beginning user could blow away there disk quota using the MH mailer and having only one rule firing on only one message. I say a "beginner, but in fact, a sensible user can do it by accident.) I have almost done this several times. I had a useful ruleset that I usually run on "inbox", and though I could save myself alot of hard work (the purpose of Lens) by running it on one of my other folders. (Unfortunately, one of the rules would've moved a particular message back into the input folder; which is where I wanted it to go...but it would have kept re-moving it to the same place forever.) This "design bug?" makes not only the ordering or rules in a sequence important to remember (already a known problem), but adds that it is important to remember which rulesets are forbidden to attempt to fire on which folders. (An interesting addition to our collect.) All in all, this seems clearly not to be a trivial problem. Even distinguishing which messages are the "same" message has interesting problems which are non-trivial. -- Brian  0,unseen,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA27322; Wed, 19 Apr 89 00:29:51 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA09922; Wed, 19 Apr 89 01:29:43 EDT Received: by PINK.MIT.EDU (5.45/4.7) id AA04629; Wed, 19 Apr 89 01:29:15 EDT Date: Wed, 19 Apr 89 01:29:15 EDT Message-Id: <8904190529.AA04629@PINK.MIT.EDU> To: mackay@ATHENA.MIT.EDU Subject: Motif Cc: alens@ATHENA.MIT.EDU, djf@ATHENA.MIT.EDU I got one of the docs last Friday and have already tried out mwm (the window manager) and the widget test programs. Both clearly are unusable at present. (For example, mwm has a bug that won't allow type-in to a text widget -- even an Athena text widget). Both also look promising and prettier than what we're used to... though terribly Macitosh-like (i.e.- all the bad parts of a Mac UI). Still, I'm dying to have shadowed buttons. Also, Gadgets are things I'm badly in need of, so I can hardly wait to use them. Hopefully, this next tape will solve these problems. It seems like they are putting alot of people-hours into this, so it looks promising. Please keep me totally informed about this. I'd appreciate getting any & all Motif related messages/mailings. -- Brian (bgardner@athena)  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA02939; Wed, 19 Apr 89 07:30:09 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA13607; Wed, 19 Apr 89 08:28:20 EDT Received: by LEO.MIT.EDU (5.60/4.7) id AA20478; Wed, 19 Apr 89 08:28:15 EDT Date: Wed, 19 Apr 89 08:28:15 EDT Message-Id: <8904191228.AA20478@LEO.MIT.EDU> To: Cc: mackay@ATHENA.MIT.EDU, alens@ATHENA.MIT.EDU In-Reply-To: Brian R Gardner's message of Wed, 19 Apr 89 01:29:15 EDT, <8904190529.AA04629@PINK.MIT.EDU> Subject: Re: Motif *** EOOH *** From: Date: Wed, 19 Apr 89 08:28:15 EDT To: Cc: mackay@ATHENA.MIT.EDU, alens@ATHENA.MIT.EDU In-Reply-To: Brian R Gardner's message of Wed, 19 Apr 89 01:29:15 EDT, <8904190529.AA04629@PINK.MIT.EDU> Subject: Re: Motif I'll be at the OSF Human Interface Symposium for one more day (Wed.), but then I hope that I'll be able to get and install the new motif tape. It should be a lot better. There are still stacks of documentation outside my door. -- David Flanagan.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA09242; Wed, 19 Apr 89 12:38:57 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA19342; Wed, 19 Apr 89 13:38:23 EDT Received: by E40-368-1.MIT.EDU (5.45/4.7) id AA20870; Wed, 19 Apr 89 13:36:24 EDT Message-Id: <8904191736.AA20870@E40-368-1.MIT.EDU> To: alens@ATHENA.MIT.EDU Subject: Meeting Schedule Date: Wed, 19 Apr 89 13:36:21 EDT *** EOOH *** From: To: alens@ATHENA.MIT.EDU Subject: Meeting Schedule Date: Wed, 19 Apr 89 13:36:21 EDT It looks like we won't have a meeting next week. Upcoming schedule: 24 April 3:00 1 May (I'll be at the CHI '89 conference) 9 May (I have jury duty -- with unknown consequences. With my luck, I'll get a 3-month sensational murder trial...) I'll be arriving back late Sunday, on May 7. So I could meet on Monday, May 8 or possibly Wednesday, May 10. Let me know if you can meet at 3:00 on either or both of those days. Wendy  1,answered,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA11078; Wed, 19 Apr 89 13:51:31 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA21009; Wed, 19 Apr 89 14:51:09 EDT Received: by MORPHEUS.MIT.EDU (5.45/4.7) id AA01371; Wed, 19 Apr 89 14:48:08 EDT Date: Wed, 19 Apr 89 14:48:08 EDT Message-Id: <8904191848.AA01371@MORPHEUS.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: [forty2!claudio: Room-temperature fusion in Italy] *** EOOH *** From: Date: Wed, 19 Apr 89 14:48:08 EDT To: rap@ATHENA.MIT.EDU Subject: [forty2!claudio: Room-temperature fusion in Italy] Rich, If you would, please translate this. A very short summary of the formalities will do. If there is anything with technical content, please translate literally and comment in square brackets (i.e. have a red day [an Italian idiom meaning "Go to Hell!"]) By the way, you made about $5 today (the market was pretty flat). Jeff ---- Resent-From: alens@ATHENA.MIT.EDU Resent-Sender: anyone@ATHENA.MIT.EDU Resent-To: jbs@ATHENA.MIT.EDU From: forty2!claudio (Claudio Nieder) Newsgroups: alt.fusion Subject: Room-temperature fusion in Italy Date: 18 Apr 89 21:33:06 GMT Organization: Exp. Physics University Zuerich Apparently-To: anyone@athena.mit.edu This evening the news program (TG1) of the italian television RAI 1 transmitted the notice, that italian scientist have discovered roomtemperature fusion in a setup which is different from that of UU or BYU. Apparently they used titanium and deuterium gas and NO electrolysis. I have written down what was said and report it here in italian, as it was transmitted. At the moment I'm preparing an english translation of this and I'll try to describe what was shown in television. Take this for the moment: Speaker Gli scienziati dell'ENEA (Ente Nazionale per l'Energia Alternativa) sono convinti di aver ottenuto un importante risultato scientifico sperimentando nel laboratorio di Frascati la fusione nucleare a freddo con un sistema del tutto diverso da quello degli scienziati americani, ma confermano che occorreranno parecchi anni perche dai successi di laboratorio si arrivi alla rivoluzione energetica attesa da tutti. Il nostro servizio sulla presentazione ufficiale dei risultati: Background Ufficio brevetti di Roma ore 11. Un rappresentante dell'ENEA sta facendo registrare il sistema per la produzione di neutroni e calore da fusione nucleare in gas assorbito su metallo. Pochi minuti e gli interessi dello stato italiano dovrebbero essere stati tutelati. Nello stesso momento in un'altra zona di Rome si sta celebrando una grande festa per l'ENEA. Sono parole del ministro per l'industria Battaglia intervenuto insieme al ministro della ricerca scientifica Ruberti, alla conferenza stampa per illustrare l'avvenuto esperimento di fusione nucleare fredda realizzato nei giorni scorsi nei laboratori di Frascati. L'attenzione e tutta per il professore Francesco Scaramuzzi, l'ideatore di un metodo che pur prendendo lo spunto dai ricercatori d'oltre oceano si discosta sensibilmente da quello utilizzato da Pons, Fleischman e Jones. Prof. Scaramuzzi: L'idea e nata col quesito, e proprio necessaria l'elettrolisi per realizzare questa interazione tra il deuterio e un metallo del tipo palladio o titanio ? E si e arrivati alla conclusione che era pensabile un esperimento relativamente semplice, per lo meno un tentativo di esperimento, ma era necessario disporre di un serio rilevamento di neutroni. E cosi e stato possibile nel giro di pochi giorni montare un semplicissimo esperimento che voleva soltanto vedere se si avevano delle indicazioni di un tipo di reazione come quello visto dagli americani. Background: Il primo esperimento e cominciato a Frascati il 7 Aprile. Due giorni dopo i primi risultati positivi, poi alcuni insuccessi, di cui presto si sono capite le cause. Infine un altro successo accompagnato da un'emissione di neutroni in quantita giudicata significativa. Niente palladio ne deuterio liquido, ne soprattutto elettrolisi, ma titanio e deuterio gassoso. Question to Prof. Scaramuzzi: Perche siete ricorsi al titanio ? Answer Prof. Scaramuzzi: Ma, avevamo analizzato un po la situazione, avevamo individuato un certo numero di metalli che sembravano interessanti e promettenti, e poi abbiamo scelto il titanio perche era disponibile, bastava prelevarlo in magazzino. Question: Pensava di avere questi risultati in cosi poco tempo ? Answer: No. Cioe quello che mi sarei aspettato ottimisticamente era di vedere dei conteggi significativi, ma non cosi elevati. Question: Quali sono le prossime tappe ? Answer: La prima tappa e completare l'esperimento come ho avuto occasione di dirle. Questo e un esperimento che e in una fase estremamente preliminare, che in condizione normali non avremmo reso pubblico a questo stadio. Background: I prossimi giorni comunque si metteranno al lavoro tre gruppi di scienziati per proseguire e approfondire la scoperta. Speaker: Il professor Umberto Colombo, presidente dell'ENEA e ospite del TG1. Abbiamo appena sentito il professore Scaramuzzi dire "Non mi aspettavo questi risultati". Quando voi avete cominciato a fare questi esperimenti, anche nel mondo accademico si e detto, va bene partecipano pure loro per stare nel gruppo. Ecco, lei se li aspettava questi risultati, voglio dire e un colpo di fortuna o e il frutto di un livello scientifico solido. Umberto Colombo: Io ricordo di essere venuto anche qua, subito dopo la scoperta di Fleischmann e Pons e avere detto, che occorreva essere prudenti, ma prendere molto sul serio questa ricerca, questa nuova strada verso la fusione nucleare. Confermo quello che ho detto allora, l'esperienza dell'ENEA ha dimostrato che si puo semplificare le condizioni sperimentali in cui hanno operato i ricercatori americani e l'inglese Fleischmann attraverso l'uso di deuterio gassoso, attraverso l'uso di un metallo in trucioli anziche attraverso il ricorso all'elettrolisi in fase liquida che poi genera problemi per i sali presenti, tutta una complicazione non necessaria. Abbiamo ottenuto un numero di neutroni molto rilevante, mille volte superiore al fondo naturale, siamo convinti che ci sia una strada da battere di estremo interesse, ma ancora non possiamo dire nulla circa le applicazioni pratiche quanto alla produzione di energia. Ecco vi voglio soprattutto dire che questo e un grande risultato scientifico, ma non e ancora un risultato che ci consente di cantare vittoria quanto alla fusione nucleare. Speaker: Professore, stamattina, come abbiamo visto prima nelle immagini, siete andati a brevettare. Questo che significa, che nessun altro, in nessun altro paese potra usare lo stesso sistema, che questo tipo di ricerca e riservato agli scienziati italiani, come funziona il brevetto di una cosa di questo genere ? Umberto Colombo: No no. La ricerca e aperta a tutti; fortunatamente ciascuno puo fare la ricerca nonostante l'esistenza di brevetti. Adesso noi cercheremo di coprire questo primo brevetto con una serie di altri brevetti mano a mano che scopriremo altre cose. Noi, e mi auguro gli altri italiani del CNR (Centro Nazionale Ricerca) dell'INFN (Istituto Nazionale per la Fisica Nucleare ?) e delle universita e dell'industria e speriamo di avere un mantello di protezione brevettuale sufficiente a batterci, perche gli altri che utilizzeranno eventualmente il processo, se mai sara applicabile, pagheranno a noi delle royalties, delle percentuali sui brevetti che abbiamo, sul costo dell'energia che avranno ci dovranno dare qualcosa se la produrranno, ammesso che questo serva per produrre energia. Speaker: Ecco: e vero professore che occorreranno, come e stato detto in questi giorni, decine di anni perche tutto questo poi possa dare dei risultati pratici sul piano energetico ? Umberto Colombo: Io ritengo che prudenza voglia che si mantenga questa asserzione. Ma io credo che sia molto diverso fare una scoperta che conduce all'osservare un flusso di neutroni. Probabilmente nelle prossime settimane osserveremo anche lo sviluppo di una quantita di energia. Ma da questo ad andare ai quantitativi di energie, alle potenze necessarie per le applicazioni industriali, c'e una strada enorme da fare e credo che la dovremo fare insieme con gli altri europei, e la dovremo fare con calma senza farci prendere da troppo facili entusiasmi e senza abbandonare le altre linee di ricerca che sono molto importanti. Speaker: Un'ultima cosa: in Italia non ci sono stati molti quattrini per la ricerca. Risultati di questo genere hanno un effetto trainante ? Umberto colombo: Io credo di si. Questa sperimentazione, ho fatto proprio il conto stamane, e costata una trentina di milioni all'ENEA. Forse qualcosa di meno. Pero sarebbe assurdo concludere che basta poco per fare la ricerca. Credo che la preparazione di questa gente, di Scaramuzzi e dei suoi colleghi, il tipo di strumentazione, il livello di sofisticazione degli strumenti di analisi, tutto richiede una mole di ricerca e di lavoro tale quale si poteva avere nel centro di Frascati e non e molto comune mettere insieme. Quindi io credo che dobbiamo tutti essere incoraggiati a favorire la ricerca in Italia. That's all for now. claudio UUCP: claudio@forty2.uucp BITNET: K538912@CZHRZU1A Mail: Claudio Nieder, Kanalweg 1, CH-8610 Uster Disclaimer: I'm not working or studying at the Physics Institute, I'm omly using their computers.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA11387; Wed, 19 Apr 89 14:02:46 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA21233; Wed, 19 Apr 89 15:00:01 EDT Received: by E40-368-1.MIT.EDU (5.45/4.7) id AA20903; Wed, 19 Apr 89 14:58:01 EDT Message-Id: <8904191858.AA20903@E40-368-1.MIT.EDU> To: video-mail@ATHENA.MIT.EDU Subject: Meeting reminder Date: Wed, 19 Apr 89 14:57:58 EDT *** EOOH *** From: To: video-mail@ATHENA.MIT.EDU Subject: Meeting reminder Date: Wed, 19 Apr 89 14:57:58 EDT Meeting on Thursday, April 20 at 4:00 in the large conference room. Some people will be away for passover, so consider your name as a placeholder for discussion. I'll defer your topic until next week if you can't be here. Handouts: Revised marketing piece Revised spec Agenda: Wendy NCGA/EAC meeting trip report Marketing progress: DEC, Hitachi, Parallax, Panasonic Introduce Debbie Hindus Win Revised architecture spec Evelyn, Brian*2 User interface Ack, Don Scheduler Dan Galatea  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA17725; Wed, 19 Apr 89 19:02:52 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA27566; Wed, 19 Apr 89 20:02:39 EDT Received: by E40-334-3.MIT.EDU (5.45/4.7) id AA02350; Wed, 19 Apr 89 20:02:25 EDT Date: Wed, 19 Apr 89 20:02:25 EDT Message-Id: <8904200002.AA02350@E40-334-3.MIT.EDU> To: jbs@ATHENA.MIT.EDU Cc: rap@ATHENA.MIT.EDU In-Reply-To: 's message of Wed, 19 Apr 89 14:48:08 EDT <8904191848.AA01371@MORPHEUS.MIT.EDU> Subject: [forty2!claudio: Room-temperature fusion in Italy] *** EOOH *** From: Date: Wed, 19 Apr 89 20:02:25 EDT To: jbs@ATHENA.MIT.EDU Cc: rap@ATHENA.MIT.EDU In-Reply-To: 's message of Wed, 19 Apr 89 14:48:08 EDT <8904191848.AA01371@MORPHEUS.MIT.EDU> Subject: [forty2!claudio: Room-temperature fusion in Italy] Jeff, the Italian is rusty, and my paper is due tomorrow, but here is a quick scan. I am trying my best to make sure nothing important slips by even though the translation is a paraphrase. Please get back to me if you need a real translation, I could do it after 6pm tomorrow (thursday) so I could have it by 7 or so--but that will probably be too late. SUMMARY: I only had time to look at a bit. But it seems that the reaction has not been duplicated. It is a reaction between DEUTRITIUM gas and a metal (it seems to be titianium) and does not use electricity. It does release large amounts of nertrons (1000 times the natural level). They are optimistic but non-commital. Stuff that I am shaky on is in quotes. From: Date: Wed, 19 Apr 89 14:48:08 EDT Rich, If you would, please translate this. A very short summary of the formalities will do. If there is anything with technical content, please translate literally and comment in square brackets (i.e. have a red day [an Italian idiom meaning "Go to Hell!"]) By the way, you made about $5 today (the market was pretty flat). Jeff ---- Resent-From: alens@ATHENA.MIT.EDU Resent-Sender: anyone@ATHENA.MIT.EDU Resent-To: jbs@ATHENA.MIT.EDU From: forty2!claudio (Claudio Nieder) Newsgroups: alt.fusion Subject: Room-temperature fusion in Italy Date: 18 Apr 89 21:33:06 GMT Organization: Exp. Physics University Zuerich Apparently-To: anyone@athena.mit.edu This evening the news program (TG1) of the italian television RAI 1 transmitted the notice, that italian scientist have discovered roomtemperature fusion in a setup which is different from that of UU or BYU. Apparently they used titanium and deuterium gas and NO electrolysis. I have written down what was said and report it here in italian, as it was transmitted. At the moment I'm preparing an english translation of this and I'll try to describe what was shown in television. Take this for the moment: Speaker Gli scienziati dell'ENEA (Ente Nazionale per l'Energia Alternativa) sono convinti di aver ottenuto un importante risultato scientifico sperimentando nel laboratorio di Frascati la fusione nucleare a freddo con un sistema del tutto diverso da quello degli scienziati americani, ma confermano che occorreranno parecchi anni perche dai successi di laboratorio si arrivi alla rivoluzione energetica attesa da tutti. Il nostro servizio sulla presentazione ufficiale dei risultati: Basically just says that they are convinced they have found a method for cold fusion which is completely different than the method discovered by the American scientists. The official notice: Background Ufficio brevetti di Roma ore 11. Un rappresentante dell'ENEA sta facendo registrare il sistema per la produzione di neutroni e calore da fusione nucleare in gas assorbito su metallo. Pochi minuti e gli interessi dello stato italiano dovrebbero essere stati tutelati. Nello stesso momento in un'altra zona di Rome si sta celebrando una grande festa per l'ENEA. Sono parole del ministro per l'industria Battaglia intervenuto insieme al ministro della ricerca scientifica Ruberti, alla conferenza stampa per illustrare l'avvenuto esperimento di fusione nucleare fredda realizzato nei giorni scorsi nei laboratori di Frascati. L'attenzione e tutta per il professore Francesco Scaramuzzi, l'ideatore di un metodo che pur prendendo lo spunto dai ricercatori d'oltre oceano si discosta sensibilmente da quello utilizzato da Pons, Fleischman e Jones. A representative of ENEA is registering a system for the production of neutrons and heat (!!) from nuclear fusion in gas "abnsorded into metal". (The theres some nationalist BS but it indicates that the liscence will be for the ENEA (an energy company MOST likely government run)). (Nothing special follows.) Prof. Scaramuzzi: L'idea e nata col quesito, e proprio necessaria l'elettrolisi per realizzare questa interazione tra il deuterio e un metallo del tipo palladio o titanio ? E si e arrivati alla conclusione che era pensabile un esperimento relativamente semplice, per lo meno un tentativo di esperimento, ma era necessario !!disporre!! di un serio rilevamento di neutroni. E cosi e stato possibile nel giro di pochi giorni montare un semplicissimo esperimento che voleva soltanto vedere se si avevano delle indicazioni di un tipo di reazione come quello visto dagli americani. They say the idea for the expireiment came from the question 'is it really necessary to use electricity to realize the interaction among deutritum (spell) and a metal like palladium or titanium?' (then it syas how the experiment is very simple and only took a few days to start). Background: Il primo esperimento e cominciato a Frascati il 7 Aprile. Due giorni dopo i primi risultati positivi, poi alcuni insuccessi, di cui presto si sono capite le cause. Infine un altro successo accompagnato da un'emissione di neutroni in quantita giudicata significativa. Niente palladio ne deuterio liquido, ne soprattutto elettrolisi, ma titanio e deuterio gassoso. (the important thing here is that they say they are getting Question to Prof. Scaramuzzi: Perche siete ricorsi al titanio ? why titanium? Answer Prof. Scaramuzzi: Ma, avevamo analizzato un po la situazione, avevamo individuato un certo numero di metalli che sembravano interessanti e promettenti, e poi abbiamo scelto il titanio perche era disponibile, bastava prelevarlo in magazzino. (bla bla.. nothing important). Question: Pensava di avere questi risultati in cosi poco tempo ? Did you ever think of such results in such a short amount of time? Answer: No. Cioe quello che mi sarei aspettato ottimisticamente era di vedere dei conteggi significativi, ma non cosi elevati. no. Question: Quali sono le prossime tappe ? Answer: La prima tappa e completare l'esperimento come ho avuto occasione di dirle. Questo e un esperimento che e in una fase estremamente preliminare, che in condizione normali non avremmo reso pubblico a questo stadio. Background: I prossimi giorni comunque si metteranno al lavoro tre gruppi di scienziati per proseguire e approfondire la scoperta. Speaker: Il professor Umberto Colombo, presidente dell'ENEA e ospite del TG1. Abbiamo appena sentito il professore Scaramuzzi dire "Non mi aspettavo questi risultati". Quando voi avete cominciato a fare questi esperimenti, anche nel mondo accademico si e detto, va bene partecipano pure loro per stare nel gruppo. Ecco, lei se li aspettava questi risultati, voglio dire e un colpo di fortuna o e il frutto di un livello scientifico solido. Umberto Colombo: Io ricordo di essere venuto anche qua, subito dopo la scoperta di Fleischmann e Pons e avere detto, che occorreva essere prudenti, ma prendere molto sul serio questa ricerca, questa nuova strada verso la fusione nucleare. Confermo quello che ho detto allora, l'esperienza dell'ENEA ha dimostrato che si puo semplificare le condizioni sperimentali in cui hanno operato i ricercatori americani e l'inglese Fleischmann attraverso l'uso di deuterio gassoso, attraverso l'uso di un metallo in trucioli anziche attraverso il ricorso all'elettrolisi in fase liquida che poi genera problemi per i sali presenti, tutta una complicazione non necessaria. Abbiamo ottenuto un numero di neutroni molto rilevante, mille volte superiore al fondo naturale, siamo convinti che ci sia una strada da battere di estremo interesse, ma ancora non possiamo dire nulla circa le applicazioni pratiche quanto alla produzione di energia. Ecco vi voglio soprattutto dire che questo e un grande risultato scientifico, ma non e ancora un risultato che ci consente di cantare vittoria quanto alla fusione nucleare. (This is the importatn paragraph. Summary above.) Speaker: Professore, stamattina, come abbiamo visto prima nelle immagini, siete andati a brevettare. Questo che significa, che nessun altro, in nessun altro paese potra usare lo stesso sistema, che questo tipo di ricerca e riservato agli scienziati italiani, come funziona il brevetto di una cosa di questo genere ? Umberto Colombo: No no. La ricerca e aperta a tutti; fortunatamente ciascuno puo fare la ricerca nonostante l'esistenza di brevetti. Adesso noi cercheremo di coprire questo primo brevetto con una serie di altri brevetti mano a mano che scopriremo altre cose. Noi, e mi auguro gli altri italiani del CNR (Centro Nazionale Ricerca) dell'INFN (Istituto Nazionale per la Fisica Nucleare ?) e delle universita e dell'industria e speriamo di avere un mantello di protezione brevettuale sufficiente a batterci, perche gli altri che utilizzeranno eventualmente il processo, se mai sara applicabile, pagheranno a noi delle royalties, delle percentuali sui brevetti che abbiamo, sul costo dell'energia che avranno ci dovranno dare qualcosa se la produrranno, ammesso che questo serva per produrre energia. Speaker: Ecco: e vero professore che occorreranno, come e stato detto in questi giorni, decine di anni perche tutto questo poi possa dare dei risultati pratici sul piano energetico ? Umberto Colombo: Io ritengo che prudenza voglia che si mantenga questa asserzione. Ma io credo che sia molto diverso fare una scoperta che conduce all'osservare un flusso di neutroni. Probabilmente nelle prossime settimane osserveremo anche lo sviluppo di una quantita di energia. Ma da questo ad andare ai quantitativi di energie, alle potenze necessarie per le applicazioni industriali, c'e una strada enorme da fare e credo che la dovremo fare insieme con gli altri europei, e la dovremo fare con calma senza farci prendere da troppo facili entusiasmi e senza abbandonare le altre linee di ricerca che sono molto importanti. Speaker: Un'ultima cosa: in Italia non ci sono stati molti quattrini per la ricerca. Risultati di questo genere hanno un effetto trainante ? Umberto colombo: Io credo di si. Questa sperimentazione, ho fatto proprio il conto stamane, e costata una trentina di milioni all'ENEA. Forse qualcosa di meno. Pero sarebbe assurdo concludere che basta poco per fare la ricerca. Credo che la preparazione di questa gente, di Scaramuzzi e dei suoi colleghi, il tipo di strumentazione, il livello di sofisticazione degli strumenti di analisi, tutto richiede una mole di ricerca e di lavoro tale quale si poteva avere nel centro di Frascati e non e molto comune mettere insieme. Quindi io credo che dobbiamo tutti essere incoraggiati a favorire la ricerca in Italia. That's all for now. claudio UUCP: claudio@forty2.uucp BITNET: K538912@CZHRZU1A Mail: Claudio Nieder, Kanalweg 1, CH-8610 Uster Disclaimer: I'm not working or studying at the Physics Institute, I'm omly using their computers.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA18477; Wed, 19 Apr 89 19:48:01 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA28315; Wed, 19 Apr 89 20:47:14 EDT Received: by E40-368-1.MIT.EDU (5.45/4.7) id AA20989; Wed, 19 Apr 89 20:45:15 EDT Message-Id: <8904200045.AA20989@E40-368-1.MIT.EDU> To: alens@ATHENA.MIT.EDU Subject: Oops... Date: Wed, 19 Apr 89 20:45:12 EDT *** EOOH *** From: To: alens@ATHENA.MIT.EDU Subject: Oops... Date: Wed, 19 Apr 89 20:45:12 EDT That was Tuesday, April 25, not Monday April 24 for next week's meeting. W  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA20786; Wed, 19 Apr 89 22:05:59 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA00677; Wed, 19 Apr 89 23:05:51 EDT Received: by PINK.MIT.EDU (5.45/4.7) id AA05053; Wed, 19 Apr 89 23:05:17 EDT Date: Wed, 19 Apr 89 23:05:17 EDT Message-Id: <8904200305.AA05053@PINK.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: bu-cs X *** EOOH *** From: Date: Wed, 19 Apr 89 23:05:17 EDT To: rap@ATHENA.MIT.EDU Subject: bu-cs X Is there (or will there be) a copy of alens on bucsf, bucsa, or other ? -- Brian  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA23869; Thu, 20 Apr 89 01:47:53 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA03276; Thu, 20 Apr 89 02:45:18 EDT Received: from [128.45.53.1] by decwrl.dec.com (5.54.5/4.7.34) id AA16534; Wed, 19 Apr 89 23:45:52 PDT Received: from [128.45.53.1] by decwrl.dec.com (5.54.5/4.7.34) for video-mail@athena.mit.edu; id AA16534; Wed, 19 Apr 89 23:45:52 PDT Received: by crl.crl.dec.com (5.57/Ultrix2.4-C) id AA15907; Thu, 20 Apr 89 02:44:22 EDT Received: by crltrx.crl.dec.com (5.57/Ultrix2.4-C) id AA08421; Thu, 20 Apr 89 02:44:47 EDT Date: Thu, 20 Apr 89 02:44:47 EDT From: treese@crl.dec.com (Win Treese) Message-Id: <8904200644.AA08421@crltrx.crl.dec.com> To: video-mail@ATHENA.MIT.EDU Subject: video mail spec Cc: treese@crl.dec.com *** EOOH *** Date: Thu, 20 Apr 89 02:44:47 EDT From: treese@crl.dec.com (Win Treese) To: video-mail@ATHENA.MIT.EDU Subject: video mail spec Cc: treese@crl.dec.com The next two messages will contain the architecture doc; one in Scribe source and one in PostScript. I received only *one* response to my request for problems/requirements/etc. Maybe the mailers are flakey. I put together a system design as best I could reconstruct things. I know it is short notice, but please try to read through the document before the meeting today. If nothing else, the section on ``Software Architecture'' was filled out quite a bit, and has some critical decisions embedded in it. There is also a partial list of outstanding issues at the end. I don't want to sound like a pessimist, or like I'm upset, but we really need to come to closure on the design and get an implementation running. There are approximately 100 days before we open now. That may sound like a lot, but it's not, especially at the rate we've been going. Apologies for the tone of this; it's rather late. So let's get out there and DO IT. - Win  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA23919; Thu, 20 Apr 89 01:54:28 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA03319; Thu, 20 Apr 89 02:52:21 EDT Received: from [128.45.53.1] by decwrl.dec.com (5.54.5/4.7.34) id AA16928; Wed, 19 Apr 89 23:52:59 PDT Received: from [128.45.53.1] by decwrl.dec.com (5.54.5/4.7.34) for video-mail@athena.mit.edu; id AA16928; Wed, 19 Apr 89 23:52:59 PDT Received: by crl.crl.dec.com (5.57/Ultrix2.4-C) id AA15918; Thu, 20 Apr 89 02:51:28 EDT Received: by crltrx.crl.dec.com (5.57/Ultrix2.4-C) id AA08462; Thu, 20 Apr 89 02:51:53 EDT Date: Thu, 20 Apr 89 02:51:53 EDT From: treese@crl.dec.com (Win Treese) Message-Id: <8904200651.AA08462@crltrx.crl.dec.com> To: video-mail@ATHENA.MIT.EDU Subject: video mail spec (more) Cc: treese@crl.dec.com *** EOOH *** Date: Thu, 20 Apr 89 02:51:53 EDT From: treese@crl.dec.com (Win Treese) To: video-mail@ATHENA.MIT.EDU Subject: video mail spec (more) Cc: treese@crl.dec.com By the way, none of what is in the document is cast in concrete as of right now. If you think it's totally wrong in some areas (or all), please let me know. The main thing I'm trying to do now is get something defined that we can discuss. - Win  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA24007; Thu, 20 Apr 89 02:02:50 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA03338; Thu, 20 Apr 89 02:55:39 EDT Received: from [128.45.53.1] by decwrl.dec.com (5.54.5/4.7.34) id AA17105; Wed, 19 Apr 89 23:56:11 PDT Received: from [128.45.53.1] by decwrl.dec.com (5.54.5/4.7.34) for video-mail@athena.mit.edu; id AA17105; Wed, 19 Apr 89 23:56:11 PDT Received: by crl.crl.dec.com (5.57/Ultrix2.4-C) id AA15926; Thu, 20 Apr 89 02:54:34 EDT Received: by crltrx.crl.dec.com (5.57/Ultrix2.4-C) id AA08492; Thu, 20 Apr 89 02:54:59 EDT Date: Thu, 20 Apr 89 02:54:59 EDT From: treese@crl.dec.com (Win Treese) Message-Id: <8904200654.AA08492@crltrx.crl.dec.com> To: video-mail@ATHENA.MIT.EDU Subject: architecture doc (source) *** EOOH *** Date: Thu, 20 Apr 89 02:54:59 EDT From: treese@crl.dec.com (Win Treese) To: video-mail@ATHENA.MIT.EDU Subject: architecture doc (source) @Device[PostScript] @Make[Report] @Comment[$Header: architecture.mss,v 1.2 89/04/20 02:54:24 treese Exp $] @Style[FontFamily TimesRoman, size 11] @Begin[TitlePage] @Begin[TitleBox] @MajorHeading[A Multi-Media Message System for SIGGRAPH '89] @Heading[Architectural Overview] @Center[Win Treese] @Center[Cambridge Research Lab] @Center[Digital Equipment Corporation] @Center[DRAFT of] @Center[@Value(Filedate)] @End[TitleBox] @I[Note to reviewers: this is still rough; it is intended to be somewhat controversial. However, ``it is better to have a plan that changes than no plan at all.''] @CopyrightNotice[Massachusetts Institute of Technology] @End[TitlePage] @PageFooting[Left="Architectural Overview", Right="Draft of @Value(FileDate)", Immediate] @Section[Introduction] In recent years, it has become feasible to manipulate a variety of communications media with a computer used by a single individual. Some of these media (e.g., simple text) have been used for many years; others, such as video, are relatively new. Some workstations are now capable of presenting text, graphics, and video on a single physical display. This integration makes it possible to develop new methods of communication between users of such systems. A large technical conference, such as SIGGRAPH, provides an ideal place to demonstrate such systems in a direct way: by providing a communications system to be used by those attending the conference. It is very difficult, particularly at a very large one, to send messages to another person. The traditional message board is unwieldy, as it is hard to search and is only checked infrequently, if at all. Many attendees use electronic mail on a daily basis, so it is an appropriate medium to provide. It would be one thing to simply provide electronic mail service for the thirty thousand people at SIGGRAPH. A more interesting, and more challenging, idea is to provide a multi-media message system that supports text, graphics, and video messages. Not only would it be possible for individuals to create and send messages to other individuals, but announcements and other information could be made available in a ``bulletin-board'' fashion. It is also appropriate to experiment with different ideas for storing and processing messages. This document describes the system architecture of a multi-media mail system for the SIGGRAPH '89 conference. It describes at a high level the basic interface seen by the user as well as the necessary hardware and software. Pygmalion is a joint effort by individuals from Digital Equipment Corporation, MIT Project Athena, the MIT Media Laboratory, and others. @Section[System Overview] In the context of SIGGRAPH '89, the system consists of approximately one hundred workstations and some additional server machines connected by a local area network. In addition to these workstations, there are roughly eighteen workstations equipped to display video images. Three of these workstations also have video cameras. Video storage is provided by approximately one hundred video disc players. Many of these players provide read/write capability. All workstations run the X Window System @Foot[X Window System is a trademark of the Massachusetts Institute of Technology.] and some variant of the UNIX@Foot[UNIX is a trademark of AT&T Bell Laboratories.] operating system. It is likely that they will be provided by several different vendors. In addition to the LAN, the video workstations and disc players are connected by coaxial cable, which provides multiple simultaneous video signals. Each workstation can select a signal to display; multiple workstations may display the same signal. From any workstation, a user may create a message to send to other individuals or to @i[anyone]. She may also read any messages sent to her. If a message contains video, the video segment must be viewed on a video workstation; the rest of the message can be read on any workstation. On a limited number of machines it is possible to create a video message. Messages may also be created and submitted in advance. For example, a company may wish to advertise its products or announce a hospitality suite. These messages will typically be sent to @i[anyone] and will be incorporated into the system before the conference begins. The capabilities of the system are intentionally limited for this project. In particular, the user interface is constrained and the network protocols used by the various subsystems are not built for real production use. Wherever possible, the protocols have been designed, however, to be extensible to use reasonable authentication and access control methods as well other techniques necessary in a less constrained network environment. @Section[Proposed User Interface] Users of the system have vastly different computer backgrounds and levels of experience. They will also have very little time to learn the system, and will have at most four days to use it. For these reasons, we have chosen to create an extremely limited, but easy to learn user interface. Users will not have access to the Unix operating system, nor will they be able to use the full power of the Information Lens mail filter. No distribution lists will be available, so that individuals will not be able to send messages to everyone in the conference. (They will, however, be able to send messages to @p[anyone], which will enable others at the conference to choose to see the message.) We will design a process that will run while the workstations are idle that teach people about the system. We will also incorporate help within the system. @subsection[Logging In] When a user walks up to any particpating workstation, she will be asked for her name and affiliation. These serve as her ``identity'' for the conference@Foot[It is possible to consider using a more secure system, but this should not be necessary for SIGGRAPH. It is at least as good as the standard paper bulletin board, and simplifies both the system design and the login process for the user.]. The system contains a ``registration database,'' which is essentially a list of all SIGGRAPH attendees and represented organizations. Identities are checked against the database using soundex@foot[Soundex checks for phonetic spellings of names.] matching on both names and affiliations. Many common abbreviations or short names for organizations (e.g., ``DEC'' or ``Digital'' for Digital Equipment Corporation) will be stored in the registration database. After ``logging in,'' she will be informed if she has any new messages. She will be able to choose to read new (or previously read) messages, create new messages, or explore the database of messages intended for anyone at SIGGRAPH. @subsection[Reading Messages] The user will be able to see a list of new and previously-read messages. She will use the mouse to point to the message she would like to see. To simplify the interface, only one message may be viewed at a time. If a message contains a video component, an appropriate single frame of the video will be displayed. If she is using a non-video workstation, a message will also appear explaining where to go to see the message on a full-video workstation. Video workstations will allow users to play, rewind, and stop the video. (Video segments will typically be less than 30 seconds long, mostly because video storage is a scarce resource.) @subsection[Sending Messages] The user may elect to send messages, either replies to her messages or new ones. Messages are addressed using the same format as names at login time: name and affiliation. If a name has more than one match in the database, the user is asked to select one from a list; confirmation is requested for a single match. It is possible to omit some information. For example, one might send a message to ``Treese, Digital Equipment Corp.'' or to ``Win Treese.'' Matching is done on the information supplied, with selection from any resulting (and possibly large) lists. Names are entered and confirmed one at a time. The special name @i[anyone] can be used to post a public message. If an affiliation is given for @i[anyone], the message is distributed to everyone with the specified affiliation. After selecting the recipients of a message, the user can type the text of the message. On a camera-equipped video workstation, she may also create a video message. Because of the resource limitations, video segments will be limited to thirty seconds. If she decides to send a message of general interest, she can send it to @p[anyone]. If desired, the user can choose to add additional fields which will help others find her message. @subsection[Reading messages sent to @p{anyone}] The user may also peruse the set of messages sent to @i[anyone]. This may be done by manually looking at ``headers'' for the entire set of message, or by composing simple rules for selecting messages. Rules are actually empty message templates. When the user types an entry into a field, the system selects messages with that entry filled in. For example, if the user is interested in messages which contain the subject ``Scientific Visualization,'' she can type that in the empty subject field and select all relevant messages. @Section[Hardware Components] Wherever possible, the hardware selected is currently available for use at MIT. It is, of course, constrained by what can actually be obtained for the conference. For concreteness, the following discussion names various types of Digital hardware; equivalent systems from other vendors may be substituted if appropriate. @SubSection[Video Workstations] Video workstations typically consist of a MicroVAX II in a BA123 cabinet, with a Parallax video interface. The Parallax interface is connected to the appropriate keyboard, color display, and mouse. They may be diskless. Ultrix 3.0 is the operating system. @SubSection[Standard Workstations] Standard workstations are typically DECstation 3100s, with display, keyboard, and mouse. They may be diskless. Ultrix 3.0 (RISC) is the operating system. @SubSection[Mail and Database Servers] The mail and database servers are DECstation 3100 systems with appropriate console interfaces and sufficient disk storage. Ultrix 3.0 is the operating system. @SubSection[Video Control Servers] The video control servers are DECstation 3100 systems with appropriate console interfaces and sufficient disk storage. They are equipped with the necessary serial interfaces to connect to the disc players; these interfaces may be provided by DECserver terminal server equipment. The videodisc players will include a large number of standard, read-only players and a limited number of Panasonic write-once (OMDR) recorders and players. @Section[Software Architecture] This section describes the components of the video mail system and the interfaces they export to each other. @SubSection[Definitions] The following terms refer to various objects in the system environment: @Begin[Description] Logical Video Storage Device (LVSD)@\A set of one or more physical disc players, treated as identical for purposes of finding a Logical Video Segment. Logical Video Segment (LVS)@\A reference to a segment of video stored on a disc. It may be replicated on multiple discs as part of a Logical Video Storage Device. Logical Video Frame Number (LVFN)@\Frame number of an LVS within an LVSD. These numbers are typically identical to the physical frame numbers. Volume@\A video disc/output channel pair for Galatea. This is a low-level internal piece of information @End[Description] @SubSection[System Initialization] The system is started at boot time as the session manager for the X window system. The login screen is displayed, and the system waits for a user to login. Once a valid user is identified, the login program changes its ID to that of the user, changes to her home directory, and executes the message browser program. @SubSection[User Interface] The user interface consists of four screen displays: @Begin[Itemize] Login Message Browser Message Composer Video Message Composer @End[Itemize] @Paragraph[Login Display] The login display is very simple; it consists of a ``pretty'' display and a window in which to type one's name and organization. Keyboard focus is on the name window initially, whether or not the mouse cursor is in the name window. @Paragraph[Message Browser] The message browser includes the following elements: @Begin[Itemize] A brief listing of available messages. The list is short (no more than 5 messages at a time), so it may be a scrollable subset of the entire message list. The list includes the name of the sender, part of the subject line, and an indication of whether or not a video segment is available (if appropriate). A view of the text of the current message. A view of the still image or video segment of the current message. Moving video is only displayed when the user explicitly starts it. Controls to reply to or forward a message. A delete control. A way to select messages based on attributes (the Lens component). A way to switch between messages to ``anyone'' and personal messages. Controls for manipulating the video (if appropriate). These are disabled when no video is available. A help control. The help system is critical to this application. An exit control. A round red button with the words ``Don't Panic'' written in large, friendly letters. @End[Itemize] User messages are stored in MH format, and normal MH tools may be used to manipulate them under control of the browser. @Paragraph[Message Composer] For messages that do not involve the creation of new video segments, the message composer contains the following: @Begin[Itemize] A way to specify recipients. An editable view of the text of the current message. A view of the still image associated with the message, if there is one. Controls for selecting the portion of the video segment to send. A help control. The help system is critical to this application. An exit control. @End[Itemize] @Paragraph[Video Message Composer] ***I have no idea how this works @SubSection[Registration Database] The registration database contains information on every user of the system. It is designed to provide rapid access to the necessary information for logging in and sending a message to a user. It is built on top of Project Athena's Hesiod name service. Information about a user is contained in the following data type: @Begin[ProgramExample] typedef struct tUserInfo { char name[MAX_NAME_LENGTH]; char organization[MAX_ORG_LENGTH]; UserID userid; } UserInfo; @End[ProgramExample] The @i[userid] field is used as both a UNIX username (in string form) and a UNIX user ID number where appropriate. The basic interface to the registration database is @i[RegGetUserInfo()]: @Begin[ProgramExample] UserInfo * RegGetUserInfo(name, organization) char *name; char *organization; @End[ProgramExample] This procedure returns a null-terminated array of UserInfo structures matching the specified name and organization. If no exact matches are generated, names are looked up using Soundex. An exact match allows for pre-defined variation in the name of the organization. The user is responsible for selecting a unique person from the list. All other requests in the system requiring information about a user are keyed by the userid. Users can be registered in three ways: @Begin[Itemize] From the SIGGRAPH pre-registration list. From the SIGGRAPH on-site registration desk. (***HOW ARE WE GOING TO HANDLE THIS?) By receiving a message before they have arrived. If a user insists on sending mail to someone who has not registered, she may do so, and the recipient is automatically registered. Such a registration is noted, and an administrator is notified. Subsequent ``nearly the same'' registrations are alerted for administrative action. Registering a user is performed by the @i[RegCreateUser()] function: @Begin[ProgramExample] ErrCode RegCreateUser(name, organization) char *name; char *organization; @End[ProgramExample] Nickname expansion is performed on the organization. Valid error codes returned include RegSuccess, RegAlreadyRegistered, RegFailure. The implementation is opaque to the user interface. Current plans call for use of Hesiod to look up both names and organizations, including Soundex and nickname lookups. @End[Itemize] @SubSection[Message Format] Messages without video are standard RFC822 messages, with the exception that the ``To:'', ``From:'', and ``Cc:'' lines are name-organization pairs, rather than actual mail addresses. Messages containing video are the same as above, with the following additional fields: @Begin[Description] X-Video@\Specifies the ID of a Logical Video Storage Device. X-Video-Start-Frame@\Specifies the starting Logical Video Frame Number. X-Video-End-Fram@\Specifies the ending Logical Video Frame Number. X-Video-Still@\Specifies the LVSD of the associated still frame. X-Video-Still-Frame@\Specifies the LVFN of the associated still frame. @End[Description] The first three fields are required for a video message; the second two are optional (but both must be present if one is). The following fields are used for still images: @Begin[Description] X-Slide@\Specifies the LVSD of the still image. X-Slide-Frame@\Specifies LVFN of the still image. @End[Description] Multiple video segments and still images may be included in a single message. Anything contained in the message but not specified above is treated as text of the message. @SubSection[Video Control Subsystem] The Video Control Subsystem consists of two parts: a scheduler for arbitrating workstation access to the video discs, and Galatea, a system for manipulating video disc players developed by Dan Applebaum at the MIT Media Laboratory. When a workstation wishes to use a disc player, it submits a request to the scheduler to obtain a time slice for controlling the player: @Begin[ProgramExample] TimeSlice * SchedGetTimeSlice(segment, start_frame, end_frame) SegmentID segment; FrameNumbern start_frame; FrameNumber end_frame; @End[ProgramExample] All three arguments are derived directly from the message. NULL is returned if no time slice may be allocated. If more information on the reason for not getting a time slice is required, @i[SchedWhatWentWrong()] may be called: @Begin[ProgramExample] ErrCode SchedWhatWentWrong() @End[ProgramExample] This procedure returns the reason the previous call to the scheduler failed. Valid results include @Begin[Description] Success@\The call really succeeded. SchedNotAvailable@\The scheduler could not be contacted. SchedQueueTooLong@\The current queue is too long for the request to be satisfied. UnknownError@\An unknown error occurred. @End[Description] If the call is successful, the following data is provided: @Begin[ProgramExample] typedef tTimeSlice { time_t start_time; time_t end_time; time_t current_time; GalateaVolumeID volume; FrameNumber start_frame; FrameNumber end_frame; } TimeSlice; @End[ProgramExample] At the beginning of the time slice, the workstation may send control requests to Galatea. The interface for Galatea is described in ***REF. Until the end of the time slice, the workstation has complete control of the disc player, within the limits of what Galatea provides. If a user would like to continue beyond the allocated time slice, another request is made of the scheduler. @B[NOTE:] should the times be sent to Galatea so it can enforce them? This is proposed not as a security feature, but a guard against bugs. A workstation may also query the scheduler as to the availability of a particular segment: @Begin[ProgramExample] Boolean SchedIsAvailable(segment) SegmentID segment; @End[ProgramExample] This function returns True if the segment is available, and False if not. Note that False implies that all physical discs containing the segment are in use. IMPLEMENTATION NOTE: A workstation is not permitted to request availability more than once per minute. This function may be implemented such that it requests a list of busy LVSDs no more often than once per minute, and returns the cached information upon request. @SubSection[Mail Service] The mail service is built around the Post Office Protocol, and @i[sendmail]. When a message is composed, it is handed off to the local @i[sendmail], which delivers it to the mail router. The mail router delivers to an appropriate Post Office server. Mail is retrieved from the post office using the MH command @i[inc]. @SubSection[Message Storage] Each user has a limited amount of disk storage for storing mail messages. This home directory is available through NFS. @Section[Back Doors] Messages to system administrators may be delivered in non-standard ways. Administrative interfaces to directly manipulate the registration database, video control subsystem, and mail service will be available. @Section[Implementation Notes] The user interface will be implemented using Digital's XUI toolkit. Depending on timeliness and availability, it may be migrated to the the Open Software Foundation Motif system. @Unnumbered[Acknowledgements] The author would like to thank Wendy Mackay, Mark Ackerman, Dan Applebaum, Don Davis, Brian Gardner, Brian Michon, and the other members of the project team for many helpful discussions leading to this document. The final content is, of course, the sole responsibility of the author. @Unnumbered[ISSUES] How is replication accomplished in an LVSD? How do we compose video messages? How are they stored to disc? Do we need a common network communications library? If so, does it need both TCP and UDP support? Are we running a window manager? If so, which one? What capabilities will it have? Is the ``palette'' of video objects a reasonable thing to attempt? @Unnumbered[CONSEQUENCES] Graphics are no longer permitted, since we have no storage format.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA24067; Thu, 20 Apr 89 02:09:13 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA03346; Thu, 20 Apr 89 02:56:11 EDT Received: from [128.45.53.1] by decwrl.dec.com (5.54.5/4.7.34) id AA17153; Wed, 19 Apr 89 23:56:37 PDT Received: from [128.45.53.1] by decwrl.dec.com (5.54.5/4.7.34) for video-mail@athena.mit.edu; id AA17153; Wed, 19 Apr 89 23:56:37 PDT Received: by crl.crl.dec.com (5.57/Ultrix2.4-C) id AA15930; Thu, 20 Apr 89 02:54:48 EDT Received: by crltrx.crl.dec.com (5.57/Ultrix2.4-C) id AA08496; Thu, 20 Apr 89 02:55:12 EDT Date: Thu, 20 Apr 89 02:55:12 EDT From: treese@crl.dec.com (Win Treese) Message-Id: <8904200655.AA08496@crltrx.crl.dec.com> To: video-mail@ATHENA.MIT.EDU Subject: architecture doc (PostScript) *** EOOH *** Date: Thu, 20 Apr 89 02:55:12 EDT From: treese@crl.dec.com (Win Treese) To: video-mail@ATHENA.MIT.EDU Subject: architecture doc (PostScript) %!PS-Adobe-1.0 %%Title: architecture.mss %%DocumentFonts: (atend) %%Creator: Win Treese,CRL,6216615, and Scribe 6(1600) %%CreationDate: 20 April 1989 01:53 %%Pages: (atend) %%EndComments % PostScript Prelude for Scribe. /BS {/SV save def 0.0 792.0 translate .01 -.01 scale} bind def /ES {showpage SV restore} bind def /SC {setrgbcolor} bind def /FMTX matrix def /RDF {WFT SLT 0.0 eq {SSZ 0.0 0.0 SSZ neg 0.0 0.0 FMTX astore} {SSZ 0.0 SLT neg sin SLT cos div SSZ mul SSZ neg 0.0 0.0 FMTX astore} ifelse makefont setfont} bind def /SLT 0.0 def /SI { /SLT exch cvr def RDF} bind def /WFT /Courier findfont def /SF { /WFT exch findfont def RDF} bind def /SSZ 1000.0 def /SS { /SSZ exch 100.0 mul def RDF} bind def /AF { /WFT exch findfont def /SSZ exch 100.0 mul def RDF} bind def /MT /moveto load def /XM {currentpoint exch pop moveto} bind def /UL {gsave newpath moveto dup 2.0 div 0.0 exch rmoveto setlinewidth 0.0 rlineto stroke grestore} bind def /LH {gsave newpath moveto setlinewidth 0.0 rlineto gsave stroke grestore} bind def /LV {gsave newpath moveto setlinewidth 0.0 exch rlineto gsave stroke grestore} bind def /BX {gsave newpath moveto setlinewidth exch dup 0.0 rlineto exch 0.0 exch neg rlineto neg 0.0 rlineto closepath gsave stroke grestore} bind def /BX1 {grestore} bind def /BX2 {setlinewidth 1 setgray stroke grestore} bind def /PB {/PV save def newpath translate 100.0 -100.0 scale pop /showpage {} def} bind def /PE {PV restore} bind def /GB {/PV save def newpath translate rotate div dup scale 100.0 -100.0 scale /showpage {} def} bind def /GE {PV restore} bind def /FB {dict dup /FontMapDict exch def begin} bind def /FM {cvn exch cvn exch def} bind def /FE {end /original-findfont /findfont load def /findfont {dup FontMapDict exch known{FontMapDict exch get} if original-findfont} def} bind def /BC {gsave moveto dup 0 exch rlineto exch 0 rlineto neg 0 exch rlineto closepath clip} bind def /EC /grestore load def /SH /show load def /MX {exch show 0.0 rmoveto} bind def /W {0 32 4 -1 roll widthshow} bind def /WX {0 32 5 -1 roll widthshow 0.0 rmoveto} bind def %%EndProlog %%Page: 0 1 BS 0 SI 16 /Times-Bold AF 12780 14032 MT (A Multi-Media Message System for SIGGRAPH '89)SH 14 SS 23504 19242 MT (Architectural Overview)SH 11 /Times-Roman AF 28050 22796 MT (Win Treese)SH 25011 24548 MT (Cambridge Research Lab)SH 23725 26300 MT (Digital Equipment Corporation)SH 28201 29429 MT (DRAFT of)SH 25589 31181 MT (20 April 1989 at 01:53)SH /Times-Italic SF 18957 40257 MT (Note to reviewers: this is still rough; it is intended to)SH 15141 41634 MT (be somewhat controversial. However, ``it is better to have a plan that)SH 24092 43011 MT (changes than no plan at all.'')SH /Times-Roman SF 17807 58480 MT (Copyright)SH /Symbol SF 22544 XM (\323)SH /Times-Roman SF 23688 XM (1989 Massachusetts) 275 W( Institute of Technology)SH ES %%Page: 1 2 BS 0 SI 10 /Times-Roman AF 30350 4286 MT (1)SH 13 /Times-Bold AF 7200 8071 MT (1 Introduction)SH 11 /Times-Roman AF 8200 9448 MT (In recent years, it has become feasible to manipulate a) 264 W( variety of communications media with a)263 W 7200 10825 MT (computer used by a single individual. Some of these media \050e.g., simple) 71 W( text\051 have been used for many)72 W 7200 12202 MT (years; others, such as video,) 89 W( are relatively new. Some workstations are now capable of presenting text,)88 W 7200 13579 MT (graphics, and video on a single physical display.) 194 W( This) 664 W( integration makes it possible to develop new)195 W 7200 14956 MT (methods of communication between users of such systems.)SH 8200 17435 MT (A large technical conference, such as SIGGRAPH, provides an ideal place to demonstrate such systems)12 W 7200 18812 MT (in a direct way: by providing a communications system to be used) 6 W( by those attending the conference. It is)7 W 7200 20189 MT (very difficult, particularly at a very large one, to send) 228 W( messages to another person. The traditional)227 W 7200 21566 MT (message board is unwieldy, as it is hard to search and is only checked infrequently, if) 180 W( at all. Many)181 W 7200 22943 MT (attendees use electronic mail on a daily basis, so it is an appropriate medium to provide.)SH 8200 25422 MT (It would be one thing) 236 W( to simply provide electronic mail service for the thirty thousand people at)235 W 7200 26799 MT (SIGGRAPH. A) 307 W( more interesting, and more challenging, idea is to provide a multi-media) 16 W( message system)17 W 7200 28176 MT (that supports text, graphics, and video messages. Not) 65 W( only would it be possible for individuals to create)64 W 7200 29553 MT (and send messages to other individuals, but announcements and other information could) 310 W( be made)311 W 7200 30930 MT (available in a ``bulletin-board'' fashion. It is also appropriate to experiment with different) 192 W( ideas for)191 W 7200 32307 MT (storing and processing messages.)SH 8200 34786 MT (This document describes the system architecture of a multi-media mail system for the SIGGRAPH '89)42 W 7200 36163 MT (conference. It) 625 W( describes at a high level the) 175 W( basic interface seen by the user as well as the necessary)174 W 7200 37540 MT (hardware and software. Pygmalion) 82 W( is a joint effort by individuals from Digital Equipment Corporation,)83 W 7200 38917 MT (MIT Project Athena, the MIT Media Laboratory, and others.)SH 13 /Times-Bold AF 7200 42668 MT (2 System Overview)SH 11 /Times-Roman AF 8200 44045 MT (In the context of SIGGRAPH '89, the system consists of approximately one) 53 W( hundred workstations and)52 W 7200 45422 MT (some additional server machines connected by a local area network.) 112 W( In) 500 W( addition to these workstations,)113 W 7200 46799 MT (there are roughly eighteen workstations equipped) 99 W( to display video images. Three of these workstations)98 W 7200 48176 MT (also have video cameras. Video storage is provided by approximately) 112 W( one hundred video disc players.)113 W 9 SS 51579 49190 MT (1)SH 11 SS 7200 49553 MT (Many of these players provide read/write capability. All) 109 W( workstations run the X Window System)108 W 52412 XM (and)SH 9 SS 18996 50567 MT (2)SH 11 SS 7200 50930 MT (some variant of the UNIX)78 W 19799 XM (operating system.) 78 W( It) 432 W( is likely that they will be provided by several different)79 W 7200 52307 MT (vendors.)SH 8200 54786 MT (In addition to the LAN, the video) 53 W( workstations and disc players are connected by coaxial cable, which)52 W 7200 56163 MT (provides multiple simultaneous video signals.) 97 W( Each) 470 W( workstation can select a signal to display; multiple)98 W 7200 57540 MT (workstations may display the same signal.)SH 8200 60019 MT (From any workstation, a user may create a message to send to other individuals or to)23 W /Times-Italic SF 46111 XM (anyone)SH /Times-Roman SF (. She) 321 W( may)23 W 7200 61396 MT (also read any messages sent to her. If a message contains video, the video segment must be viewed on a)43 W 7200 62773 MT (video workstation; the rest of the message can be read on any workstation. On a limited number) 175 W( of)174 W 7200 64150 MT (machines it is possible to) 215 W( create a video message. Messages may also be created and submitted in)216 W 7200 65527 MT (advance. For) 555 W( example, a company may wish) 140 W( to advertise its products or announce a hospitality suite.)139 W 10800 50 7200 68144 UL 7 SS 8100 69645 MT (1)SH 9 SS 8450 69972 MT (X Window System is a trademark of the Massachusetts Institute of Technology.)SH 7 SS 8100 71673 MT (2)SH 9 SS 8450 72000 MT (UNIX is a trademark of AT&T Bell Laboratories.)SH 10 SS 7200 75600 MT (Architectural Overview)SH 41446 XM (Draft of 20 April 1989 at 01:53)SH ES %%Page: 2 3 BS 0 SI 10 /Times-Roman AF 30350 4286 MT (2)SH 11 SS 7200 7955 MT (These messages will typically be sent to)191 W /Times-Italic SF 26470 XM (anyone)SH /Times-Roman SF 30112 XM (and will be incorporated into the system before the)191 W 7200 9332 MT (conference begins.)SH 8200 11811 MT (The capabilities of the system are intentionally limited for this project.) 45 W( In) 363 W( particular, the user interface)44 W 7200 13188 MT (is constrained and the network protocols used) 49 W( by the various subsystems are not built for real production)50 W 7200 14565 MT (use. Wherever) 477 W( possible, the protocols) 101 W( have been designed, however, to be extensible to use reasonable)100 W 7200 15942 MT (authentication and access control methods as well other techniques necessary in a less) 280 W( constrained)281 W 7200 17319 MT (network environment.)SH 13 /Times-Bold AF 7200 21070 MT (3 Proposed User Interface)SH 11 /Times-Roman AF 8200 22447 MT (Users of the system have vastly different computer backgrounds and levels of experience.) 101 W( They) 475 W( will)100 W 7200 23824 MT (also have very little time to learn) 37 W( the system, and will have at most four days to use it. For these reasons,)38 W 7200 25201 MT (we have chosen to create) 171 W( an extremely limited, but easy to learn user interface. Users will not have)170 W 7200 26578 MT (access to the Unix) 70 W( operating system, nor will they be able to use the full power of the Information Lens)71 W 7200 27955 MT (mail filter. No distribution) 34 W( lists will be available, so that individuals will not be able to send messages to)33 W 7200 29332 MT (everyone in the conference. \050They will, however, be able to send messages to)31 W /Times-BoldItalic SF 42237 XM (anyone)SH /Times-Roman SF (, which will enable)31 W 7200 30709 MT (others at the conference to choose to see the message.\051)SH 8200 33188 MT (We will design a process that will run while the workstations are) 195 W( idle that teach people about the)194 W 7200 34565 MT (system. We) 275 W( will also incorporate help within the system.)SH 12 /Times-Bold AF 7200 38249 MT (3.1 Logging In)SH 11 /Times-Roman AF 8200 39626 MT (When a user walks) 79 W( up to any particpating workstation, she will be asked for her name and affiliation.)80 W 9 SS 28788 40640 MT (3)SH 11 SS 7200 41003 MT (These serve as her) 17 W( ``identity'' for the conference)18 W 29238 XM (. The) 311 W( system contains a ``registration database,'' which)18 W 7200 42380 MT (is essentially a list of all SIGGRAPH attendees and represented) 160 W( organizations. Identities are checked)159 W 9 SS 24280 43394 MT (4)SH 11 SS 7200 43757 MT (against the database using soundex)421 W 25426 XM (matching on both names and affiliations. Many) 421 W( common)422 W 7200 45134 MT (abbreviations or short names for organizations \050e.g., ``DEC'' or ``Digital'') 329 W( for Digital Equipment)328 W 7200 46511 MT (Corporation\051 will be stored in the registration database.)SH 8200 48990 MT (After ``logging in,'' she will be informed if she has any new messages. She will be) 66 W( able to choose to)67 W 7200 50367 MT (read new \050or previously read\051 messages, create new messages, or explore) 237 W( the database of messages)236 W 7200 51744 MT (intended for anyone at SIGGRAPH.)SH 12 /Times-Bold AF 7200 55428 MT (3.2 Reading Messages)SH 11 /Times-Roman AF 8200 56805 MT (The user will be able to) 125 W( see a list of new and previously-read messages. She will use the mouse to)126 W 7200 58182 MT (point to the message she) 10 W( would like to see. To simplify the interface, only one message may be viewed at)9 W 7200 59559 MT (a time.)SH 8200 62038 MT (If a message contains a video component,) 12 W( an appropriate single frame of the video will be displayed. If)13 W 7200 63415 MT (she is using) 213 W( a non-video workstation, a message will also appear explaining where to go to see the)212 W 7200 64792 MT (message on a full-video workstation. Video workstations) 89 W( will allow users to play, rewind, and stop the)90 W 10800 50 7200 67130 UL 7 SS 8100 68631 MT (3)SH 9 SS 8450 68958 MT (It is possible to consider using a more secure system, but this should not be) 40 W( necessary for SIGGRAPH. It is at least as good)39 W 7200 69972 MT (as the standard paper bulletin board, and simplifies both the system design and the login process for the user.)SH 7 SS 8100 71673 MT (4)SH 9 SS 8450 72000 MT (Soundex checks for phonetic spellings of names.)SH 10 SS 7200 75600 MT (Architectural Overview)SH 41446 XM (Draft of 20 April 1989 at 01:53)SH ES %%Page: 3 4 BS 0 SI 10 /Times-Roman AF 30350 4286 MT (3)SH 11 SS 7200 7955 MT (video. \050Video) 509 W( segments will typically be less than 30 seconds long,) 117 W( mostly because video storage is a)116 W 7200 9332 MT (scarce resource.\051)SH 12 /Times-Bold AF 7200 13016 MT (3.3 Sending Messages)SH 11 /Times-Roman AF 8200 14393 MT (The user may elect) 223 W( to send messages, either replies to her messages or new ones. Messages are)224 W 7200 15770 MT (addressed using the same format as names at login time: name and affiliation. If) 60 W( a name has more than)59 W 7200 17147 MT (one match in the database, the) 4 W( user is asked to select one from a list; confirmation is requested for a single)5 W 7200 18524 MT (match. It) 553 W( is possible to omit some information. For example, one might send a message to ``Treese,)139 W 7200 19901 MT (Digital Equipment Corp.'' or) 202 W( to ``Win Treese.'' Matching is done on the information supplied, with)203 W 7200 21278 MT (selection from any resulting \050and possibly large\051 lists. Names are entered and confirmed one at a) 92 W( time.)91 W 7200 22655 MT (The special name)55 W /Times-Italic SF 15336 XM (anyone)SH /Times-Roman SF 18842 XM (can be used to post a public message. If an) 55 W( affiliation is given for)56 W /Times-Italic SF 48874 XM (anyone)SH /Times-Roman SF (, the)56 W 7200 24032 MT (message is distributed to everyone with the specified affiliation.)SH 8200 26511 MT (After selecting the recipients of a message, the) 111 W( user can type the text of the message. On a camera-)110 W 7200 27888 MT (equipped video workstation, she may also create a video message. Because of the resource limitations,)94 W 7200 29265 MT (video segments will be limited to thirty seconds.)SH 8200 31744 MT (If she decides) 41 W( to send a message of general interest, she can send it to)40 W /Times-BoldItalic SF 39650 XM (anyone)SH /Times-Roman SF (. If) 355 W( desired, the user can)40 W 7200 33121 MT (choose to add additional fields which will help others find her message.)SH 12 /Times-Bold AF 7200 36830 MT (3.4 Reading messages sent to)SH /Times-BoldItalic SF 22201 XM (anyone)SH 11 /Times-Roman AF 8200 38207 MT (The user may also peruse the set of messages sent) 6 W( to)7 W /Times-Italic SF 31635 XM (anyone)SH /Times-Roman SF (. This) 289 W( may be done by manually looking at)7 W 7200 39584 MT (``headers'' for the entire) 39 W( set of message, or by composing simple rules for selecting messages. Rules are)38 W 7200 40961 MT (actually empty message templates. When the user types an entry into a) 16 W( field, the system selects messages)17 W 7200 42338 MT (with that entry filled in. For example, if the user is interested) 153 W( in messages which contain the subject)152 W 7200 43715 MT (``Scientific Visualization,'' she can type that in the empty subject field and select all relevant messages.)SH 13 /Times-Bold AF 7200 47466 MT (4 Hardware Components)SH 11 /Times-Roman AF 8200 48843 MT (Wherever possible, the hardware selected is currently available for) 247 W( use at MIT. It is, of course,)248 W 7200 50220 MT (constrained by what can actually be obtained for the conference.) 289 W( For) 852 W( concreteness, the following)288 W 7200 51597 MT (discussion names various types of) 232 W( Digital hardware; equivalent systems from other vendors may be)233 W 7200 52974 MT (substituted if appropriate.)SH 12 /Times-Bold AF 7200 56658 MT (4.1 Video Workstations)SH 11 /Times-Roman AF 8200 58035 MT (Video workstations typically consist of a MicroVAX II in a BA123 cabinet, with a) 186 W( Parallax video)185 W 7200 59412 MT (interface. The) 625 W( Parallax interface is connected to the appropriate keyboard,) 175 W( color display, and mouse.)176 W 7200 60789 MT (They may be diskless. Ultrix 3.0 is the operating system.)SH 12 /Times-Bold AF 7200 64473 MT (4.2 Standard Workstations)SH 11 /Times-Roman AF 8200 65850 MT (Standard workstations are typically DECstation 3100s, with) 62 W( display, keyboard, and mouse. They may)61 W 7200 67227 MT (be diskless. Ultrix 3.0 \050RISC\051 is the operating system.)SH 10 SS 7200 75600 MT (Architectural Overview)SH 41446 XM (Draft of 20 April 1989 at 01:53)SH ES %%Page: 4 5 BS 0 SI 10 /Times-Roman AF 30350 4286 MT (4)SH 12 /Times-Bold AF 7200 8004 MT (4.3 Mail and Database Servers)SH 11 /Times-Roman AF 8200 9381 MT (The mail and database servers) 132 W( are DECstation 3100 systems with appropriate console interfaces and)133 W 7200 10758 MT (sufficient disk storage. Ultrix 3.0 is the operating system.)SH 12 /Times-Bold AF 7200 14442 MT (4.4 Video Control Servers)SH 11 /Times-Roman AF 8200 15819 MT (The video control) 315 W( servers are DECstation 3100 systems with appropriate console interfaces and)314 W 7200 17196 MT (sufficient disk storage. They are equipped with the necessary serial interfaces to connect to the) 178 W( disc)179 W 7200 18573 MT (players; these interfaces may be provided by DECserver terminal server equipment.)SH 8200 21052 MT (The videodisc players will include a large number of standard, read-only players) 48 W( and a limited number)47 W 7200 22429 MT (of Panasonic write-once \050OMDR\051 recorders and players.)SH 13 /Times-Bold AF 7200 26180 MT (5 Software Architecture)SH 11 /Times-Roman AF 8200 27557 MT (This section describes the components of the video mail) 67 W( system and the interfaces they export to each)68 W 7200 28934 MT (other.)SH 12 /Times-Bold AF 7200 32618 MT (5.1 Definitions)SH 11 /Times-Roman AF 8200 33995 MT (The following terms refer to various objects in the system environment:)SH 7200 35946 MT (Logical Video Storage Device \050LVSD\051)SH 16000 37142 MT (A set of one or more physical disc) 20 W( players, treated as identical for purposes of finding)21 W 16000 38338 MT (a Logical Video Segment.)SH 7200 40033 MT (Logical Video Segment \050LVS\051)SH 16000 41229 MT (A reference to a segment of video stored on a disc. It) 61 W( may be replicated on multiple)62 W 16000 42425 MT (discs as part of a Logical Video Storage Device.)SH 7200 44120 MT (Logical Video Frame Number \050LVFN\051)SH 16000 45316 MT (Frame number of an LVS within an LVSD. These numbers are typically identical) 50 W( to)51 W 16000 46512 MT (the physical frame numbers.)SH 7200 48207 MT (Volume)SH 16000 XM (A video disc/output channel pair for) 147 W( Galatea. This is a low-level internal piece of)146 W 16000 49403 MT (information)SH 12 /Times-Bold AF 7200 53087 MT (5.2 System Initialization)SH 11 /Times-Roman AF 8200 54464 MT (The system is started at boot time as the session manager for) 6 W( the X window system. The login screen is)7 W 7200 55841 MT (displayed, and the system waits for a user) 126 W( to login. Once a valid user is identified, the login program)125 W 7200 57218 MT (changes its ID to that of the user, changes to her) 178 W( home directory, and executes the message browser)179 W 7200 58595 MT (program.)SH 12 /Times-Bold AF 7200 62279 MT (5.3 User Interface)SH 11 /Times-Roman AF 8200 63656 MT (The user interface consists of four screen displays:)SH /Symbol SF 9169 65234 MT (\267)SH /Times-Roman SF 9950 XM (Login)SH /Symbol SF 9169 67128 MT (\267)SH /Times-Roman SF 9950 XM (Message Browser)SH /Symbol SF 9169 69022 MT (\267)SH /Times-Roman SF 9950 XM (Message Composer)SH /Symbol SF 9169 70916 MT (\267)SH /Times-Roman SF 9950 XM (Video Message Composer)SH 10 SS 7200 75600 MT (Architectural Overview)SH 41446 XM (Draft of 20 April 1989 at 01:53)SH ES %%Page: 5 6 BS 0 SI 10 /Times-Roman AF 30350 4286 MT (5)SH 11 /Times-Bold AF 7200 7937 MT (5.3.1 Login Display)SH /Times-Roman SF 8200 9314 MT (The login display is very simple; it consists of a ``pretty'' display and a window in which to type) 26 W( one's)25 W 7200 10691 MT (name and) 1 W( organization. Keyboard focus is on the name window initially, whether or not the mouse cursor)2 W 7200 12068 MT (is in the name window.)SH /Times-Bold SF 7200 14965 MT (5.3.2 Message Browser)SH /Times-Roman SF 8200 16342 MT (The message browser includes the following elements:)SH /Symbol SF 9169 17920 MT (\267)SH /Times-Roman SF 9950 XM (A brief listing of available messages. The list is short \050no more than 5) 68 W( messages at a time\051,)67 W 9950 19116 MT (so it may be a scrollable subset of the entire message list. The list includes) 64 W( the name of the)65 W 9950 20312 MT (sender, part of the subject line, and) 226 W( an indication of whether or not a video segment is)225 W 9950 21508 MT (available \050if appropriate\051.)SH /Symbol SF 9169 23402 MT (\267)SH /Times-Roman SF 9950 XM (A view of the text of the current message.)SH /Symbol SF 9169 25296 MT (\267)SH /Times-Roman SF 9950 XM (A view of the still image or video segment of the current message. Moving video is only)122 W 9950 26492 MT (displayed when the user explicitly starts it.)SH /Symbol SF 9169 28386 MT (\267)SH /Times-Roman SF 9950 XM (Controls to reply to or forward a message.)SH /Symbol SF 9169 30280 MT (\267)SH /Times-Roman SF 9950 XM (A delete control.)SH /Symbol SF 9169 32174 MT (\267)SH /Times-Roman SF 9950 XM (A way to select messages based on attributes \050the Lens component\051.)SH /Symbol SF 9169 34068 MT (\267)SH /Times-Roman SF 9950 XM (A way to switch between messages to ``anyone'' and personal messages.)SH /Symbol SF 9169 35962 MT (\267)SH /Times-Roman SF 9950 XM (Controls for manipulating the video \050if appropriate\051. These are disabled when) 129 W( no video is)128 W 9950 37158 MT (available.)SH /Symbol SF 9169 39052 MT (\267)SH /Times-Roman SF 9950 XM (A help control. The help system is critical to this application.)SH /Symbol SF 9169 40946 MT (\267)SH /Times-Roman SF 9950 XM (An exit control.)SH /Symbol SF 9169 42840 MT (\267)SH /Times-Roman SF 9950 XM (A round red button with the words ``Don't Panic'' written in large, friendly letters.)SH 8200 45319 MT (User messages are) 59 W( stored in MH format, and normal MH tools may be used to manipulate them under)60 W 7200 46696 MT (control of the browser.)SH /Times-Bold SF 7200 49593 MT (5.3.3 Message Composer)SH /Times-Roman SF 8200 50970 MT (For messages that do not involve the creation of new video segments, the message) 72 W( composer contains)71 W 7200 52347 MT (the following:)SH /Symbol SF 9169 53925 MT (\267)SH /Times-Roman SF 9950 XM (A way to specify recipients.)SH /Symbol SF 9169 55819 MT (\267)SH /Times-Roman SF 9950 XM (An editable view of the text of the current message.)SH /Symbol SF 9169 57713 MT (\267)SH /Times-Roman SF 9950 XM (A view of the still image associated with the message, if there is one.)SH /Symbol SF 9169 59607 MT (\267)SH /Times-Roman SF 9950 XM (Controls for selecting the portion of the video segment to send.)SH /Symbol SF 9169 61501 MT (\267)SH /Times-Roman SF 9950 XM (A help control. The help system is critical to this application.)SH /Symbol SF 9169 63395 MT (\267)SH /Times-Roman SF 9950 XM (An exit control.)SH /Times-Bold SF 7200 66292 MT (5.3.4 Video Message Composer)SH /Times-Roman SF 8200 67669 MT (***I have no idea how this works)SH 10 SS 7200 75600 MT (Architectural Overview)SH 41446 XM (Draft of 20 April 1989 at 01:53)SH ES %%Page: 6 7 BS 0 SI 10 /Times-Roman AF 30350 4286 MT (6)SH 12 /Times-Bold AF 7200 8004 MT (5.4 Registration Database)SH 11 /Times-Roman AF 8200 9381 MT (The registration database contains information on every user of the system. It is designed to) 96 W( provide)97 W 7200 10758 MT (rapid access to the necessary information for logging in and sending a message to a user.) 9 W( It) 292 W( is built on top)8 W 7200 12135 MT (of Project Athena's Hesiod name service.)SH 8200 14614 MT (Information about a user is contained in the following data type:)SH /Courier-Bold SF 9840 16272 MT (typedef struct tUserInfo {)SH 15120 17496 MT (char name[MAX_NAME_LENGTH];)SH 15120 18720 MT (char organization[MAX_ORG_LENGTH];)SH 15120 19944 MT (UserID userid;)SH 9840 21168 MT (} UserInfo;)SH /Times-Roman SF 8200 23647 MT (The)SH /Times-Italic SF 10234 XM (userid)SH /Times-Roman SF 13308 XM (field is used as both a UNIX username \050in string form\051 and a UNIX user ID) 49 W( number where)50 W 7200 25024 MT (appropriate.)SH 8200 27503 MT (The basic interface to the registration database is)SH /Times-Italic SF 29946 XM (RegGetUserInfo\050\051)SH /Times-Roman SF (:)SH /Courier-Bold SF 9840 29161 MT (UserInfo *)SH 9840 30385 MT (RegGetUserInfo\050name, organization\051)SH 9840 31609 MT (char *name;)SH 9840 32833 MT (char *organization;)SH /Times-Roman SF 7200 34505 MT (This procedure returns a null-terminated array of) 140 W( UserInfo structures matching the specified name and)139 W 7200 35882 MT (organization. If) 463 W( no exact matches are generated, names are looked up using Soundex. An exact match)94 W 7200 37259 MT (allows for pre-defined variation in the name of the organization.)SH 8200 39738 MT (The user is responsible for selecting a unique person from the list.)SH 8200 42217 MT (All other requests in the system requiring information about a user are keyed by the userid.)SH 8200 44696 MT (Users can be registered in three ways:)SH /Symbol SF 9169 46274 MT (\267)SH /Times-Roman SF 9950 XM (From the SIGGRAPH pre-registration list.)SH /Symbol SF 9169 48168 MT (\267)SH /Times-Roman SF 9950 XM (From the) 62 W( SIGGRAPH on-site registration desk. \050***HOW ARE WE GOING TO HANDLE)61 W 9950 49364 MT (THIS?\051)SH /Symbol SF 9169 51258 MT (\267)SH /Times-Roman SF 9950 XM (By receiving a message before they have arrived. If a user) 250 W( insists on sending mail to)251 W 9950 52454 MT (someone who) 25 W( has not registered, she may do so, and the recipient is automatically registered.)24 W 9950 53650 MT (Such a registration) 34 W( is noted, and an administrator is notified. Subsequent ``nearly the same'')35 W 9950 54846 MT (registrations are alerted for administrative action.)SH /Symbol SF 9169 56740 MT (\267)SH /Times-Roman SF 9950 XM (Registering a user is performed by the)SH /Times-Italic SF 27025 XM (RegCreateUser\050\051)SH /Times-Roman SF 34874 XM (function:)SH /Courier-Bold SF 12590 58398 MT (ErrCode)SH 12590 59622 MT (RegCreateUser\050name, organization\051)SH 12590 60846 MT (char *name;)SH 12590 62070 MT (char *organization;)SH /Symbol SF 9169 63964 MT (\267)SH /Times-Roman SF 9950 XM (Nickname expansion is performed) 126 W( on the organization. Valid error codes returned include)125 W 9950 65160 MT (RegSuccess, RegAlreadyRegistered, RegFailure.)SH /Symbol SF 9169 67054 MT (\267)SH /Times-Roman SF 9950 XM (The implementation is opaque to the user interface. Current plans call for use) 82 W( of Hesiod to)83 W 9950 68250 MT (look up both names and organizations, including Soundex and nickname lookups.)SH 10 SS 7200 75600 MT (Architectural Overview)SH 41446 XM (Draft of 20 April 1989 at 01:53)SH ES %%Page: 7 8 BS 0 SI 10 /Times-Roman AF 30350 4286 MT (7)SH 12 /Times-Bold AF 7200 8004 MT (5.5 Message Format)SH 11 /Times-Roman AF 8200 9381 MT (Messages without video are standard RFC822 messages, with the exception that the ``To:'', ``From:'',)50 W 7200 10758 MT (and ``Cc:'' lines are name-organization pairs, rather than actual mail addresses.)SH 8200 13237 MT (Messages containing video are the same as above, with the following additional fields:)SH 7200 15188 MT (X-Video)SH 16000 XM (Specifies the ID of a Logical Video Storage Device.)SH 7200 16883 MT (X-Video-Start-Frame)SH 16000 18079 MT (Specifies the starting Logical Video Frame Number.)SH 7200 19774 MT (X-Video-End-Fram)SH 16000 XM (Specifies the ending Logical Video Frame Number.)SH 7200 21469 MT (X-Video-Still)SH 16000 XM (Specifies the LVSD of the associated still frame.)SH 7200 23164 MT (X-Video-Still-Frame)SH 16000 24360 MT (Specifies the LVFN of the associated still frame.)SH 7200 26311 MT (The first three) 142 W( fields are required for a video message; the second two are optional \050but both must be)143 W 7200 27688 MT (present if one is\051.)SH 8200 30167 MT (The following fields are used for still images:)SH 7200 32118 MT (X-Slide)SH 16000 XM (Specifies the LVSD of the still image.)SH 7200 33813 MT (X-Slide-Frame)SH 16000 XM (Specifies LVFN of the still image.)SH 8200 36292 MT (Multiple video segments and still images may be included in a single message. Anything contained) 46 W( in)45 W 7200 37669 MT (the message but not specified above is treated as text of the message.)SH 12 /Times-Bold AF 7200 41353 MT (5.6 Video Control Subsystem)SH 11 /Times-Roman AF 8200 42730 MT (The Video Control Subsystem consists of two parts: a) 107 W( scheduler for arbitrating workstation access to)108 W 7200 44107 MT (the video discs, and Galatea, a system for manipulating video disc players developed by) 39 W( Dan Applebaum)38 W 7200 45484 MT (at the MIT Media Laboratory.)SH 8200 47963 MT (When a workstation wishes to use a disc player, it submits a request to the scheduler to) 79 W( obtain a time)80 W 7200 49340 MT (slice for controlling the player:)SH /Courier-Bold SF 9840 50998 MT (TimeSlice *)SH 9840 52222 MT (SchedGetTimeSlice\050segment, start_frame, end_frame\051)SH 9840 53446 MT (SegmentID segment;)SH 9840 54670 MT (FrameNumbern start_frame;)SH 9840 55894 MT (FrameNumber end_frame;)SH /Times-Roman SF 8200 58373 MT (All three arguments are derived directly) 66 W( from the message. NULL is returned if no time slice may be)65 W 7200 59750 MT (allocated. If) 1615 W( more information on the reason for not getting a time) 670 W( slice is required,)671 W /Times-Italic SF 7200 61127 MT (SchedWhatWentWrong\050\051)SH /Times-Roman SF 18409 XM (may be called:)SH /Courier-Bold SF 9840 62785 MT (ErrCode)SH 9840 64009 MT (SchedWhatWentWrong\050\051)SH /Times-Roman SF 8200 66488 MT (This procedure returns the reason the previous call to the scheduler failed. Valid results include)SH 7200 68439 MT (Success)SH 16000 XM (The call really succeeded.)SH 7200 70134 MT (SchedNotAvailable)SH 16000 XM (The scheduler could not be contacted.)SH 7200 71829 MT (SchedQueueTooLong)SH 10 SS 7200 75600 MT (Architectural Overview)SH 41446 XM (Draft of 20 April 1989 at 01:53)SH ES %%Page: 8 9 BS 0 SI 10 /Times-Roman AF 30350 4286 MT (8)SH 11 SS 16000 7955 MT (The current queue is too long for the request to be satisfied.)SH 7200 9650 MT (UnknownError)SH 16000 XM (An unknown error occurred.)SH 8200 12129 MT (If the call is successful, the following data is provided:)SH /Courier-Bold SF 9840 13787 MT (typedef tTimeSlice {)SH 15120 15011 MT (time_t start_time;)660 W 15120 16235 MT (time_t end_time;)660 W 15120 17459 MT (time_t current_time;)660 W 15120 18683 MT (GalateaVolumeID volume;)SH 15120 19907 MT (FrameNumber start_frame;)SH 15120 21131 MT (FrameNumber end_frame;)SH 9840 22355 MT (} TimeSlice;)SH /Times-Roman SF 8200 24834 MT (At the beginning of the time slice, the workstation may send control requests) 52 W( to Galatea. The interface)53 W 7200 26211 MT (for Galatea is described in ***REF. Until the end of the time slice, the workstation has) 34 W( complete control)33 W 7200 27588 MT (of the disc player, within the limits of what Galatea provides. If) 21 W( a user would like to continue beyond the)22 W 7200 28965 MT (allocated time slice, another request is made of the scheduler.)SH /Times-Bold SF 8200 31444 MT (NOTE:)SH /Times-Roman SF 12010 XM (should the times be sent to Galatea so it can enforce them? This is proposed) 51 W( not as a security)50 W 7200 32821 MT (feature, but a guard against bugs.)SH 8200 35300 MT (A workstation may also query the scheduler as to the availability of a particular segment:)SH /Courier-Bold SF 9840 36958 MT (Boolean)SH 9840 38182 MT (SchedIsAvailable\050segment\051)SH 9840 39406 MT (SegmentID segment;)SH /Times-Roman SF 8200 41885 MT (This function returns True if the segment is available, and False if not. Note that False implies that) 42 W( all)43 W 7200 43262 MT (physical discs containing the segment are in use.)SH 8200 45741 MT (IMPLEMENTATION NOTE: A workstation is not permitted to request availability) 15 W( more than once per)14 W 7200 47118 MT (minute. This) 319 W( function may be implemented such that it requests a list of busy LVSDs) 22 W( no more often than)23 W 7200 48495 MT (once per minute, and returns the cached information upon request.)SH 12 /Times-Bold AF 7200 52179 MT (5.7 Mail Service)SH 11 /Times-Roman AF 8200 53556 MT (The mail service is built) 21 W( around the Post Office Protocol, and)20 W /Times-Italic SF 35674 XM (sendmail)SH /Times-Roman SF (. When) 315 W( a message is composed,)20 W 7200 54933 MT (it is handed off to the) 53 W( local)54 W /Times-Italic SF 19640 XM (sendmail)SH /Times-Roman SF (, which delivers it to the mail router. The mail router delivers to an)54 W 7200 56310 MT (appropriate Post Office server. Mail is retrieved from the post office using the MH command)SH /Times-Italic SF 48711 XM (inc)SH /Times-Roman SF (.)SH 12 /Times-Bold AF 7200 59994 MT (5.8 Message Storage)SH 11 /Times-Roman AF 8200 61371 MT (Each user has a limited amount of disk storage for storing mail messages.) 175 W( This) 623 W( home directory is)174 W 7200 62748 MT (available through NFS.)SH 13 /Times-Bold AF 7200 66499 MT (6 Back Doors)SH 11 /Times-Roman AF 8200 67876 MT (Messages to system administrators may be delivered in non-standard ways.) 82 W( Administrative) 441 W( interfaces)83 W 7200 69253 MT (to directly manipulate the registration database,) 299 W( video control subsystem, and mail service will be)298 W 7200 70630 MT (available.)SH 10 SS 7200 75600 MT (Architectural Overview)SH 41446 XM (Draft of 20 April 1989 at 01:53)SH ES %%Page: 9 10 BS 0 SI 10 /Times-Roman AF 30350 4286 MT (9)SH 13 /Times-Bold AF 7200 8071 MT (7 Implementation Notes)SH 11 /Times-Roman AF 8200 9448 MT (The user interface will) 196 W( be implemented using Digital's XUI toolkit. Depending on timeliness and)197 W 7200 10825 MT (availability, it may be migrated to the the Open Software Foundation Motif system.)SH 10 SS 7200 75600 MT (Architectural Overview)SH 41446 XM (Draft of 20 April 1989 at 01:53)SH ES %%Page: 10 11 BS 0 SI 10 /Times-Roman AF 30100 4286 MT (10)SH 14 /Times-Bold AF 7200 8138 MT (Acknowledgements)SH 11 /Times-Roman AF 8200 9515 MT (The author would like to) 78 W( thank Wendy Mackay, Mark Ackerman, Dan Applebaum, Don Davis, Brian)77 W 7200 10892 MT (Gardner, Brian Michon, and the other members of the project team for) 59 W( many helpful discussions leading)60 W 7200 12269 MT (to this document. The final content is, of course, the sole responsibility of the author.)SH 10 SS 7200 75600 MT (Architectural Overview)SH 41446 XM (Draft of 20 April 1989 at 01:53)SH ES %%Page: 11 12 BS 0 SI 10 /Times-Roman AF 30100 4286 MT (11)SH 14 /Times-Bold AF 7200 8138 MT (ISSUES)SH 11 /Times-Roman AF 8200 9515 MT (How is replication accomplished in an LVSD?)SH 8200 11994 MT (How do we compose video messages? How are they stored to disc?)SH 8200 14473 MT (Do we need a common network communications) 197 W( library? If so, does it need both TCP and UDP)196 W 7200 15850 MT (support?)SH 8200 18329 MT (Are we running a window manager? If so, which one? What capabilities will it have?)SH 8200 20808 MT (Is the ``palette'' of video objects a reasonable thing to attempt?)SH 10 SS 7200 75600 MT (Architectural Overview)SH 41446 XM (Draft of 20 April 1989 at 01:53)SH ES %%Page: 12 13 BS 0 SI 10 /Times-Roman AF 30100 4286 MT (12)SH 14 /Times-Bold AF 7200 8138 MT (CONSEQUENCES)SH 11 /Times-Roman AF 8200 9515 MT (Graphics are no longer permitted, since we have no storage format.)SH 10 SS 7200 75600 MT (Architectural Overview)SH 41446 XM (Draft of 20 April 1989 at 01:53)SH ES %%Page: i 14 BS 0 SI 10 /Times-Roman AF 30461 4286 MT (i)SH 14 /Times-Bold AF 25272 8138 MT (Table of Contents)SH 12 SS 9000 9394 MT (1 Introduction)SH 53400 XM (1)SH 9000 10650 MT (2 System Overview)SH 53400 XM (1)SH 9000 11906 MT (3 Proposed User Interface)SH 53400 XM (2)SH 11 SS 11050 13074 MT (3.1 Logging In)SH 53450 XM (2)SH 11050 14242 MT (3.2 Reading Messages)SH 53450 XM (2)SH 11050 15410 MT (3.3 Sending Messages)SH 53450 XM (3)SH 11050 16578 MT (3.4 Reading messages sent to)SH /Times-BoldItalic SF 24798 XM (anyone)SH /Times-Bold SF 53450 XM (3)SH 12 SS 9000 17834 MT (4 Hardware Components)SH 53400 XM (3)SH 11 SS 11050 19002 MT (4.1 Video Workstations)SH 53450 XM (3)SH 11050 20170 MT (4.2 Standard Workstations)SH 53450 XM (3)SH 11050 21338 MT (4.3 Mail and Database Servers)SH 53450 XM (4)SH 11050 22506 MT (4.4 Video Control Servers)SH 53450 XM (4)SH 12 SS 9000 23762 MT (5 Software Architecture)SH 53400 XM (4)SH 11 SS 11050 24930 MT (5.1 Definitions)SH 53450 XM (4)SH 11050 26098 MT (5.2 System Initialization)SH 53450 XM (4)SH 11050 27266 MT (5.3 User Interface)SH 53450 XM (4)SH 13250 28434 MT (5.3.1 Login Display)SH 53450 XM (5)SH 13250 29602 MT (5.3.2 Message Browser)SH 53450 XM (5)SH 13250 30770 MT (5.3.3 Message Composer)SH 53450 XM (5)SH 13250 31938 MT (5.3.4 Video Message Composer)SH 53450 XM (5)SH 11050 33106 MT (5.4 Registration Database)SH 53450 XM (6)SH 11050 34274 MT (5.5 Message Format)SH 53450 XM (7)SH 11050 35442 MT (5.6 Video Control Subsystem)SH 53450 XM (7)SH 11050 36610 MT (5.7 Mail Service)SH 53450 XM (8)SH 11050 37778 MT (5.8 Message Storage)SH 53450 XM (8)SH 12 SS 9000 39034 MT (6 Back Doors)SH 53400 XM (8)SH 9000 40290 MT (7 Implementation Notes)SH 53400 XM (9)SH 13 SS 7200 41634 MT (Acknowledgements)SH 52700 XM (10)SH 7200 42978 MT (ISSUES)SH 52700 XM (11)SH 7200 44322 MT (CONSEQUENCES)SH 52700 XM (12)SH 10 /Times-Roman AF 7200 75600 MT (Architectural Overview)SH 41446 XM (Draft of 20 April 1989 at 01:53)SH ES %%Trailer %%Pages: 14 %%DocumentFonts: Times-Roman Times-Bold Times-Italic Symbol Times-BoldItalic Courier-Bold  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA28229; Thu, 20 Apr 89 09:26:44 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA07953; Thu, 20 Apr 89 10:24:01 EDT Received: by FLOTSAM.MIT.EDU (5.45/4.8) id AA09756; Thu, 20 Apr 89 10:23:29 EDT From: Daniel I. Applebaum Message-Id: <8904201423.AA09756@FLOTSAM.MIT.EDU> To: treese@crl.dec.com (Win Treese) Cc: video-mail@ATHENA.MIT.EDU Subject: Re: architecture doc (source) In-Reply-To: Your message of Thu, 20 Apr 89 02:54:59 EDT. <8904200654.AA08492@crltrx.crl.dec.com> Date: Thu, 20 Apr 89 09:23:26 EST *** EOOH *** From: Daniel I. Applebaum To: treese@crl.dec.com (Win Treese) Cc: video-mail@ATHENA.MIT.EDU Subject: Re: architecture doc (source) In-Reply-To: Your message of Thu, 20 Apr 89 02:54:59 EDT. <8904200654.AA08492@crltrx.crl.dec.com> Date: Thu, 20 Apr 89 09:23:26 EST Very impressive. I had at one point started writing a subsystem in Galatea which could enforce time slices. This is extremely easy to do when you only have a single master server, and no local servers. It is extremely difficult to do once you've got local servers. We could do away with the local servers, if that is felt to be necessary. In fact, I'm not sure we gain anything by having local servers. Let me think about this some more. Anyway, I had decided to stop writing the time slice enforcer, since I hoped that we could trust all the pieces in the system. I guess my opinion is that if we can't trust the pieces, we should give up now. Dan.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA03680; Thu, 20 Apr 89 13:16:13 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA13083; Thu, 20 Apr 89 14:14:01 EDT Received: from crl.dec.com by decwrl.dec.com (5.54.5/4.7.34) id AA29821; Thu, 20 Apr 89 11:12:42 PDT Received: from crl.dec.com by decwrl.dec.com (5.54.5/4.7.34) for video-mail@athena.mit.edu; id AA29821; Thu, 20 Apr 89 11:12:42 PDT Received: by crl.crl.dec.com (5.57/Ultrix2.4-C) id AA16610; Thu, 20 Apr 89 14:10:51 EDT Message-Id: <8904201809.AA11029@cirocco.DEC.COM> To: danapple@flotsam.mit.edu (Daniel I. Applebaum 20-Apr-89 0923 EST) Cc: video-mail@ATHENA.MIT.EDU Subject: Galatea changes In-Reply-To: Your message of Thu, 20 Apr 89 10:26:14 -0400. Date: Thu, 20 Apr 89 14:09:36 EDT From: Win Treese *** EOOH *** To: danapple@flotsam.mit.edu (Daniel I. Applebaum 20-Apr-89 0923 EST) Cc: video-mail@ATHENA.MIT.EDU Subject: Galatea changes In-Reply-To: Your message of Thu, 20 Apr 89 10:26:14 -0400. Date: Thu, 20 Apr 89 14:09:36 EDT From: Win Treese I'd like to talk more about whether or not to use the local Galatea servers as well. The main point of Galatea enforcing the timestamps is that while I trust all parts of the system to do the right thing in principle (at least for SIGGRAPH), it seems that this is an easy-to-implement defense against a class of potential bugs in the workstation client software. - Win  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA27812; Fri, 21 Apr 89 14:10:13 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08502; Fri, 21 Apr 89 15:08:57 EDT Received: by PINK.MIT.EDU (5.45/4.7) id AA06466; Fri, 21 Apr 89 15:08:17 EDT Date: Fri, 21 Apr 89 15:08:17 EDT Message-Id: <8904211908.AA06466@PINK.MIT.EDU> To: alens@ATHENA.MIT.EDU Subject: Note on the name "Argos". *** EOOH *** From: Date: Fri, 21 Apr 89 15:08:17 EDT To: alens@ATHENA.MIT.EDU Subject: Note on the name "Argos". I did abit of looking around, and it turns out that "Argos" is not the Greek name for "Argus". Argos is a kingdom of Greece mentioned by Homer. It's king was a leader of the Greeks at Troy. Argus is a 100-eyes giant by Hera to watch IO. The two are related through the same story, however. In that, IO was the daughter of the king of Argos. Zeus had an interest in IO (of course, Zeus had a heafty libeto as we all know). This made his wife Hera, who was also his sister, quite jealous. Hence the reason that Hera sent Argus to spy on IO with his 100 eyes. (You can read more about this in your local library. :-) I've copied afew pages out of "The Merriam-Webster Pocket Dictionary of Proper Names" that states this stuff fairly briefly; I've given these pages to Wendy. -- Brian  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA03770; Fri, 21 Apr 89 18:23:44 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA13700; Fri, 21 Apr 89 19:22:03 EDT Received: by TARTAROS.MIT.EDU (5.60/4.7) id AA20838; Fri, 21 Apr 89 19:21:58 EDT Date: Fri, 21 Apr 89 19:21:58 EDT Message-Id: <8904212321.AA20838@TARTAROS.MIT.EDU> To: mackay@ATHENA.MIT.EDU Cc: video-mail@ATHENA.MIT.EDU *** EOOH *** From: Date: Fri, 21 Apr 89 19:21:58 EDT To: mackay@ATHENA.MIT.EDU Cc: video-mail@ATHENA.MIT.EDU wendy, if we can get a half-dozen read-only copies made of a bunch of video-segments that get made at the show, we could continue to run this demo on mit's own equipment, after the show. this would likely please various people-who-wear-suits, like catherine avril, earll murman, jim bruce... -don  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA05051; Fri, 21 Apr 89 19:55:14 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA14870; Fri, 21 Apr 89 20:54:02 EDT Received: from [128.45.53.1] by decwrl.dec.com (5.54.5/4.7.34) id AA15438; Fri, 21 Apr 89 14:59:06 PDT Received: from [128.45.53.1] by decwrl.dec.com (5.54.5/4.7.34) for alens@athena.mit.edu; id AA15438; Fri, 21 Apr 89 14:59:06 PDT Received: by crl.crl.dec.com (5.57/Ultrix2.4-C) id AA18276; Fri, 21 Apr 89 17:57:17 EDT Message-Id: <8904212155.AA00188@cirocco.DEC.COM> To: bgardner@ATHENA.MIT.EDU (21-Apr-89 1508 EDT) Cc: alens@ATHENA.MIT.EDU Subject: Re: Note on the name "Argos". In-Reply-To: Your message of Fri, 21 Apr 89 15:09:49 -0400. Date: Fri, 21 Apr 89 17:55:53 EDT From: Win Treese *** EOOH *** To: bgardner@ATHENA.MIT.EDU (21-Apr-89 1508 EDT) Cc: alens@ATHENA.MIT.EDU Subject: Re: Note on the name "Argos". In-Reply-To: Your message of Fri, 21 Apr 89 15:09:49 -0400. Date: Fri, 21 Apr 89 17:55:53 EDT From: Win Treese This was bothering me the other day, actually, since I couldn't figure out the Argos (with an 'O') connection. Argus is a bit confusing as a name, since it has been used elsewhere, including a current project at LCS. - Win  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA05355; Fri, 21 Apr 89 20:20:13 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA15157; Fri, 21 Apr 89 21:18:09 EDT Received: by TARTAROS.MIT.EDU (5.60/4.7) id AA20869; Fri, 21 Apr 89 21:18:04 EDT Date: Fri, 21 Apr 89 21:18:04 EDT Message-Id: <8904220118.AA20869@TARTAROS.MIT.EDU> To: treese@ATHENA.MIT.EDU Cc: video-mail@ATHENA.MIT.EDU *** EOOH *** From: Date: Fri, 21 Apr 89 21:18:04 EDT To: treese@ATHENA.MIT.EDU Cc: video-mail@ATHENA.MIT.EDU win, having read the spec, i compliment your clarity & thoroughness; nice work. i necessarily concentrated on the low-level guts. my comments follow: Page 3, Sending messages: i must plead that general users not be allowed unrestrictedly to send messages to "anyone". otherwise, either: * this will waste the limited capacity for high-popularity segments; or * we humans will have to judge which "anyone" messages get high-popularity storage. i don't know any way to so judge, that scales to thousands of users. btw, if general users can excerpt high-popularity messages, we won't be able to retire as many excerpted high-pop LVSDs/disks. this further limits our capacity for high-pop segments. try to remember that most of the system's waiting time comes from high-popularity segments' use; therefore, we don't want to amplify these segments' popularity, even though we do want to be popular. page 6, bottom third: "Subsequent 'nearly the same' registrations are alerted for administrative action." if by "admin. action" you mean WE intervene, this won't scale to 30k registrations, because these collisions will happen frequently. rather, the automatically registered users should automatically be asked to resolve these name-collisions, when they register themselves. note that a "can't win" situation will sometimes obtain, where two senders cause two receivers to be registered automatically under the same name, "c smith, ibm." Nickname expansion: the code that pattern-matches this stuff will have to be clever about punting, since people will often fuck up important attributes like company affiliation: "AMD" for "Amdahl". alternatively, we could be explicitly stupid, and not try to deliver mis-addressed mail. page 7, "message format:" i'm worried about how faithful disk-to-disk copy can be. will these message-id's necessarily specify the same bits on two supposedly identical disks? can frames get dropped during copying, for example? danny? SchedWWWrong(): i don't like the idea of the scheduler having to keep this much state on hand. SchedGTSlice() should extract an errorcode from the scheduler's response, and keep the errorcode on hand for the SchedWWWrong() call to return. Alternatively, and more robustly, the error-code could be part of the timeslice structure, and SchedWWW() could be eliminated, so that galatea would have an extra opportunity to catch bugs in the scheduler and ui code. Page 8, top third: we need to guard against race-conditions, here. the system should be forgiving about "at the beginning of the time slice", whenever possible. is this possible? i think the scheduler should provide some separate free-play in the time-slices, so that galatea can more easily make judgement- calls about whether the ui is too late with its segment-request. this free-play is expensive, and thus probably needs to be automatically tuned, via feedback from galatea. (?) Page 8: midpage NOTE: i like the idea of the scheduler sending times to galatea simultaneously, but i worry about race conditions... Page 8: SchedIsAvailable() should return more info than a boolean, possibly a time, or queue-length, so that the ui code can respond. typically, a busy LVSD won't be busy for long. Page 8: IMPL. NOTE: i'm not sure i understand who "returns [what] cached info", but one thing worries me: don't hard-code the constraint of 1/minute, so we can tweak this parameter at show-time. Page 8, mail service: i think the system should automatically inc the guy's mail at startup/login. i remember having the damnedest time understanding what "inc" was for, and why it was necessary, when i came to athena from a less aggressively-networked unix shop. it seems to me that it's not necessary at the show, because the users' sessions provide only mail, anyway. i hope this is helpful. i know the spec is. -don  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA24910; Sat, 22 Apr 89 21:32:32 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA00891; Sat, 22 Apr 89 22:30:53 EDT Received: by E40-368-1.MIT.EDU (5.45/4.7) id AA23158; Sat, 22 Apr 89 22:28:19 EDT Message-Id: <8904230228.AA23158@E40-368-1.MIT.EDU> To: video-mail@ATHENA.MIT.EDU Subject: Action Items... Date: Sat, 22 Apr 89 22:28:16 EDT *** EOOH *** From: To: video-mail@ATHENA.MIT.EDU Subject: Action Items... Date: Sat, 22 Apr 89 22:28:16 EDT *************************** Due: What: Tues Biographies needed: Please send me a one-paragraph biography of 4/25 who you are. Examples at the end of this message. Thurs Read Win's Spec! Give comments, preferably on line! 4/27 Wed What decisions are you waiting for? (e.g. expiration dates? UI issues?) Let me know what is holding you up, so we can discuss and decide on April 27. *************************** Decisions from last meeting: 1. Brian G will use the Motif style and allow resizing of windows 2. Wendy will work with Brian M and Evelyn on process-oriented UI spec, separate from the architecture spec. 3. Next week, the meeting will have two components: marketing and technical. Several people cannot come until 4:30, so we'll start then. Please try to be on time! 4. Vendor ads will be available on a broadcast channel. 5. Expiration dates: I'm not sure what the conclusion was. 6. Equipment list was created and given to Digital. 7. We need a volunteer to handle printing if we're going to take that on.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA25075; Sat, 22 Apr 89 21:42:25 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA00999; Sat, 22 Apr 89 22:41:06 EDT Received: by E40-368-1.MIT.EDU (5.45/4.7) id AA23168; Sat, 22 Apr 89 22:38:29 EDT Message-Id: <8904230238.AA23168@E40-368-1.MIT.EDU> To: video-mail@ATHENA.MIT.EDU Subject: ...and the name is Date: Sat, 22 Apr 89 22:38:27 EDT *** EOOH *** From: To: video-mail@ATHENA.MIT.EDU Subject: ...and the name is Date: Sat, 22 Apr 89 22:38:27 EDT Well, folks, I made an executive decision. Actually, what has happened is that both vendors and the SIGGRAPH committee know us as Pygmalion. It was still possible to change it, but my reasoning for sticking with it is the following: The story (of a sculptor who creates a beautiful statue, called Galatea, who comes to life) matches what we're doing -- people can create beautiful things and bring them to life. People can pronounce it. People remember it. (Interestingly, they remember the "mail" part of Pygmalion, a serendipitous cue.) Internally, we didn't come up with something that was clearly better, liked by the majority, pronounceable, and suitable for giving out to sponsors. So, Pygmalion it is. We can still "tune into WCMS"...but it will be an inside joke. Wombats unite. Slings and arrows to Wendy...  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA27322; Sun, 23 Apr 89 01:48:42 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA03482; Sun, 23 Apr 89 02:48:37 EDT Received: by E40-368-1.MIT.EDU (5.45/4.7) id AA23297; Sun, 23 Apr 89 02:46:01 EDT Message-Id: <8904230646.AA23297@E40-368-1.MIT.EDU> To: rap@ATHENA.MIT.EDU Subject: So how did it go??? W Date: Sun, 23 Apr 89 02:45:58 EDT *** EOOH *** From: To: rap@ATHENA.MIT.EDU Subject: So how did it go??? W Date: Sun, 23 Apr 89 02:45:58 EDT  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA02678; Sun, 23 Apr 89 14:10:01 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08932; Sun, 23 Apr 89 15:06:50 EDT Received: by FLOTSAM.MIT.EDU (5.45/4.8) id AA15536; Sun, 23 Apr 89 15:06:04 EDT From: Daniel I. Applebaum Message-Id: <8904231906.AA15536@FLOTSAM.MIT.EDU> To: video-mail@ATHENA.MIT.EDU Cc: hkbirke@FLOTSAM.MIT.EDU, gid@MEDIA-LAB.MEDIA.MIT.EDU Subject: New Galatea functions Date: Sun, 23 Apr 89 14:06:01 EST *** EOOH *** From: Daniel I. Applebaum To: video-mail@ATHENA.MIT.EDU Cc: hkbirke@FLOTSAM.MIT.EDU, gid@MEDIA-LAB.MEDIA.MIT.EDU Subject: New Galatea functions Date: Sun, 23 Apr 89 14:06:01 EST Per my discussion with Win on Thurs, I have fully implemented the time slice verification section of Galatea. Although the code exists, I have not tested it yet. Also, these do not check frame numbers, only time slices. Here are the functions: int GRegisterTimeSlice(serv, time_slice) Server *serv; TimeSlice *time_slice; This function registers the given time slice with the specified Galatea server. A TimeSlice is defined as: typedef struct tTimeSlice { time_t start_time; time_t end_time; time_t current_time; char volume[30]; int start_frame; int end_frame; } TimeSlice; The verification is only done on the specified volume. The client may still fully access any other volume. int GCancelTimeSlice( serv ) Server *serv; This function cancels any previously registered time slice on the specified Galatea server. Dan.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA03314; Sun, 23 Apr 89 14:48:55 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA09500; Sun, 23 Apr 89 15:47:40 EDT Received: by FLOTSAM.MIT.EDU (5.45/4.8) id AA15578; Sun, 23 Apr 89 15:46:52 EDT From: Daniel I. Applebaum Message-Id: <8904231946.AA15578@FLOTSAM.MIT.EDU> To: video-mail@ATHENA.MIT.EDU Cc: hkbirke@MEDIA-LAB.MEDIA.MIT.EDU, gid@MEDIA-LAB.MEDIA.MIT.EDU Subject: Change of plans Date: Sun, 23 Apr 89 14:46:46 EST *** EOOH *** From: Daniel I. Applebaum To: video-mail@ATHENA.MIT.EDU Cc: hkbirke@MEDIA-LAB.MEDIA.MIT.EDU, gid@MEDIA-LAB.MEDIA.MIT.EDU Subject: Change of plans Date: Sun, 23 Apr 89 14:46:46 EST Why not check the frame numbers? No particular reason, so now the Galatea server will check the validity of the frame numbers you give it in later commands. (Note: GRun() will always fail the frame number test) Dan.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA05695; Sun, 23 Apr 89 17:30:14 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11531; Sun, 23 Apr 89 18:29:53 EDT Received: by E40-115A-1.MIT.EDU (5.45/4.7) id AA04688; Sun, 23 Apr 89 18:29:43 EDT Message-Id: <8904232229.AA04688@E40-115A-1.MIT.EDU> To: Cc: alens@ATHENA.MIT.EDU Subject: Re: possible problem in move-to In-Reply-To: Your message of Tue, 18 Apr 89 23:20:19 -0400. <8904190320.AA28206@MORPHEUS.MIT.EDU> Date: Sun, 23 Apr 89 18:29:38 EDT *** EOOH *** From: To: Cc: alens@ATHENA.MIT.EDU Subject: Re: possible problem in move-to In-Reply-To: Your message of Tue, 18 Apr 89 23:20:19 -0400. <8904190320.AA28206@MORPHEUS.MIT.EDU> Date: Sun, 23 Apr 89 18:29:38 EDT The %contains-word operator does not work on words separated by @,#,$,%,& etc. I tried it once, and it didn't fire on my message. However, it seems an easy change to implement a word separator as a blank or one of those other characters.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA09133; Sun, 23 Apr 89 22:01:47 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA14865; Sun, 23 Apr 89 22:57:35 EDT Received: by E40-368-1.MIT.EDU (5.45/4.7) id AA23990; Sun, 23 Apr 89 22:54:47 EDT Message-Id: <8904240254.AA23990@E40-368-1.MIT.EDU> To: video-mail@ATHENA.MIT.EDU Subject: oops...forgot to include the bio examples. Here they are...W Date: Sun, 23 Apr 89 22:54:44 EDT *** EOOH *** From: To: video-mail@ATHENA.MIT.EDU Subject: oops...forgot to include the bio examples. Here they are...W Date: Sun, 23 Apr 89 22:54:44 EDT @b[Wendy Mackay] @bar[] Wendy Mackay has worked for Digital for ten years, with over 8 years of technical management experience. She built and managed a $2 million software development group (2 supervisors, with 33 developers who produced 35 separate software products, shipped on time and under budget in a period of less than 3 years). She also created a $2 million Research and Development group (3 supervisors, 18 researchers who produced software that reduced the cost of multi-media software development to 1/5 of previous costs with a significant increase in user satisfaction.) Ms. Mackay managed video for the CHI '86 conference and is an elected member of the executive committee of acm/SIGCHI. She speaks frequently at national and international conferences and is the author of over twenty technical articles. Ms. Mackay is completing her Ph.D. at M.I.T. under a full scholarship from Digital. @b[Suzanne Watzman (Watzman+Keyes)] @bar[] Suzanne Watzman is co-founder and Chairman of Watzman+Keys. She is a noted authority on the subjects of information technology and design, and speaks frequently at national and international conferences. In addition to her activities as principal of Watzman+Keyes, Ms. Watzman is an advisor to the Bentley College Program in Business Communications, is on the Advisory Board for Datapro Reports on Electronic Publishing, and is a staff member of the M.I.T. Technical Communication Program. Ms. Watzman has taught at M.I.T. and graduated from The Rhode Island School of Design. @b[Win Treese] @bar[] Win Treese is currently a member of the technical research staff at Digital's Cambridge Research Laboratory. After graduating from M.I.T., he took over responsibility for release engineering at M.I.T.'s Project Athena. Mr. Treese has made many technical contributions to the Athena software environment and is the author of several technical papers.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA11016; Mon, 24 Apr 89 00:57:42 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA16617; Mon, 24 Apr 89 01:55:09 EDT Received: from crl.dec.com by decwrl.dec.com (5.54.5/4.7.34) id AA08820; Sun, 23 Apr 89 22:55:18 PDT Received: from crl.dec.com by decwrl.dec.com (5.54.5/4.7.34) for video-mail@athena.mit.edu; id AA08820; Sun, 23 Apr 89 22:55:18 PDT Received: by crl.crl.dec.com (5.57/Ultrix2.4-C) id AA01247; Mon, 24 Apr 89 01:53:46 EDT Message-Id: <8904240552.AA01588@cirocco.DEC.COM> To: rfrench@ATHENA.MIT.EDU (Robert S. French 20-Apr-89 2352 EDT) Cc: video-mail@ATHENA.MIT.EDU Subject: Re: Video mail proposal In-Reply-To: Your message of Thu, 20 Apr 89 23:52:12 -0400. Date: Mon, 24 Apr 89 01:52:39 EDT From: Win Treese *** EOOH *** To: rfrench@ATHENA.MIT.EDU (Robert S. French 20-Apr-89 2352 EDT) Cc: video-mail@ATHENA.MIT.EDU Subject: Re: Video mail proposal In-Reply-To: Your message of Thu, 20 Apr 89 23:52:12 -0400. Date: Mon, 24 Apr 89 01:52:39 EDT From: Win Treese [Rob made some comments on the architecture spec; I'm including his text here with responses, hoping he doesn't mind :-)] > The large red "Don't Panic" should be kept...I guess it isn't green > because of copyright infringements? :-) For some reason red stuck in my mind. Can be changed... > What is a "UserID"? A string or a number? Deliberately an opaque type, but I think it is actually a number -- the UNIX uid. > I'm confused as to how you intend to use Hesiod for soundex lookup. > That sounds like a really hard feature to add to me... The nameserver contains precomputed soundex keys for relevant data; to make the lookup, the client computes the soundex key and requests first-soundex.last-soundex with name type "soundex" or something like that. > Make sure that users can't delete messages. Any reason why, other than to avoid the agony of accidental deletion? > I hope the scheduler is taking into account time skew...asking for a > slice for a particular range of frames seems error-prone if done too > precisely. I've been assuming there is some allowance for that. Mark, Don? > Are you seriously considering executing real MH commands like "inc"? > Talk about a failure point you have no control over...talking directly > to the POP servers isn't that hard and seems much easier to handle. > Also this will probably be faster. > On POP and MH in general: Storing in MH format is fine, but I'm not > sure using explicit MH commands is a good idea...too many h> idden > failure points. Also if something goes wrong or you need to change > something, you're dead in the water. Ever looked at the MH source > code? Especially to the POP server. > What's the point of going through sendmail and POP when you've got > publicly accessible NFS sitting there? Why not just copy the file in > directly? Appropriate locking could be provided. Nice idea. The MH/POP notions were evolutionary out of some earlier ideas, but I like the idea of doing direct writes. > Re: common network communications library - Sun RPC works well under > both UDP and TCP, and rpcgen gives you a spec language for > automatically creating RPC routines. I'm skeptical about "works well" for Sun RPC in general, given my experience with it. In any case, this is almost a non-issue. Everything but the scheduler now has existing communications code. I'm a bit reluctant to use RPC for the scheduler, although I could possibly be convinced, especially if someone is volunteering to write code. > Make sure we make everything as colorful as tastefully possible :-) Of course. What about, O UI people? - Win  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA11117; Mon, 24 Apr 89 01:09:25 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA16664; Mon, 24 Apr 89 02:06:21 EDT Received: from crl.dec.com by decwrl.dec.com (5.54.5/4.7.34) id AA09264; Sun, 23 Apr 89 23:06:39 PDT Received: from crl.dec.com by decwrl.dec.com (5.54.5/4.7.34) for video-mail@athena.mit.edu; id AA09264; Sun, 23 Apr 89 23:06:39 PDT Received: by crl.crl.dec.com (5.57/Ultrix2.4-C) id AA01263; Mon, 24 Apr 89 02:05:08 EDT Message-Id: <8904240604.AA01601@cirocco.DEC.COM> To: don@ATHENA.MIT.EDU (21-Apr-89 2118 EDT) Cc: video-mail@ATHENA.MIT.EDU In-Reply-To: Your message of Fri, 21 Apr 89 21:19:50 -0400. Date: Mon, 24 Apr 89 02:04:01 EDT From: Win Treese *** EOOH *** To: don@ATHENA.MIT.EDU (21-Apr-89 2118 EDT) Cc: video-mail@ATHENA.MIT.EDU In-Reply-To: Your message of Fri, 21 Apr 89 21:19:50 -0400. Date: Mon, 24 Apr 89 02:04:01 EDT From: Win Treese > Page 3, Sending messages: i must plead that general users not be allowed > unrestrictedly to send messages to "anyone". otherwise, either: > * this will waste the limited capacity for high-popularity segments; or > * we humans will have to judge which "anyone" messages get high-popularity > storage. i don't know any way to so judge, that scales to thousands of users. What kind of restrictions are possible, other than "you can't do it"? It doesn't seem to me that this is really a problem, or at least a risk we have to take. I understand your concern, though. Anyone else have some thoughts on this? > btw, if general users can excerpt high-popularity messages, we won't > be able to retire as many excerpted high-pop LVSDs/disks. this further limits > our capacity for high-pop segments. try to remember that most of the system's > waiting time comes from high-popularity segments' use; therefore, we don't wa nt > to amplify these segments' popularity, even though we do want to be popular. > page 6, bottom third: > "Subsequent 'nearly the same' registrations are alerted for administrat> ive > action." if by "admin. action" you mean WE intervene, this won't scale to > 30k registrations, because these collisions will happen frequently. rather, > the automatically registered users should automatically be asked to resolve > these name-collisions, when they register themselves. note that > a "can't win" situation will sometimes obtain, where two senders cause two > receivers to be registered automatically under the same name, "c smith, ibm." Wendy, did you get the expected numbers for on-site registrations? There should have been a description of the automatic collision-resolution mechanism; I omitted it by mistake. It works along the lines you describe. I expect that there will be a fair amount of administrative overhead for us here in any case, and I don't know any way to avoid it. > Nickname expansion: the code that pattern-matches this stuff will have to be > clever about punting, since people will often fuck up important attributes li ke > company affiliation: "AMD" for "Amdahl". alternatively, we could be explicitl y > stupid, and not try to deliver mis-addressed mail. I'll do the best I can. Remember that the system won't accept a non-deliverable address in a To: line at all. The real question is how good the software is at sorting out names so that users won't be frustrated by it. > page 7, "message format:" i'm worried about how faithful disk-to-disk copy > can be. will these message-id's necessarily specify the same bits on two > supposedly identical disks? can frames get dropped during copying, for exampl e? > danny? Any answers here? > SchedWWWrong(): i don't like the idea of the sched> uler having to keep this much > state on hand. SchedGTSlice() should extract an errorcode from the scheduler' s > response, and keep the errorcode on hand for the SchedWWWrong() call to retur n. > Alternatively, and more robustly, the error-code could be part of the timesli ce > structure, and SchedWWW() could be eliminated, so that galatea would have an > extra opportunity to catch bugs in the scheduler and ui code. I wasn't sufficiently clear. Any error state is maintained by the client-side of the scheduler access library. As it stands, SWWW is needed because no time slice structure is returned with an error. Would the clients rather get back an unusable time slice structure and check an error code contained therein? > Page 8, top third: we need to guard against race-conditions, here. the system > should be forgiving about "at the beginning of the time slice", whenever > possible. is this possible? i think the scheduler should provide some separat e > free-play in the time-slices, so that galatea can more easily make judgement- > calls about whether the ui is too late with its segment-request. > this free-play is expensive, and thus probably needs to be automatically tune d, > via feedback from galatea. (?) Reasonable; we need to think about all the timing issues in some coherent way. In addition to the ones noted here, there is also network delay, processing delay, and clock skew. > Page 8: midpage NOTE: i like the idea of the scheduler sending times to galat ea > simultaneously, but i worry about race conditions> ... I'd rather not have that layer of interaction, to simplify the system. > Page 8: SchedIsAvailable() should return more info than a boolean, possibly > a time, or queue-length, so that the ui code can respond. typically, a busy > LVSD won't be busy for long. Any suggestions for what it should return? As in actual data structures? > Page 8: IMPL. NOTE: i'm not sure i understand who "returns [what] cached info ", > but one thing worries me: don't hard-code the constraint of 1/minute, > so we can tweak this parameter at show-time. The client scheduler access library caches the information; this implementation detail is hidden from the UI. Not hard-coding it is a good idea, though. > Page 8, mail service: i think the system should automatically inc the guy's > mail at startup/login. i remember having the damnedest time understanding > what "inc" was for, and why it was necessary, when i came to athena from > a less aggressively-networked unix shop. it seems to me that it's not necessa ry > at the show, because the users' sessions provide only mail, anyway. The only vestige of MH left at this point is the mail storage format (which is very simple. I have been assuming that the UI will "do the right thing", whether that turns out to be displaying new messages at login, or saying "You have new mail. Click here to see it." - Win  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA11134; Mon, 24 Apr 89 01:11:18 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA16673; Mon, 24 Apr 89 02:08:35 EDT Received: from crl.dec.com by decwrl.dec.com (5.54.5/4.7.34) id AA09318; Sun, 23 Apr 89 23:08:55 PDT Received: from crl.dec.com by decwrl.dec.com (5.54.5/4.7.34) for video-mail@athena.mit.edu; id AA09318; Sun, 23 Apr 89 23:08:55 PDT Received: by crl.crl.dec.com (5.57/Ultrix2.4-C) id AA01267; Mon, 24 Apr 89 02:07:25 EDT Received: by crltrx.crl.dec.com (5.57/Ultrix2.4-C) id AA28330; Mon, 24 Apr 89 02:08:15 EDT Date: Mon, 24 Apr 89 02:08:15 EDT From: treese@crl.dec.com (Win Treese) Message-Id: <8904240608.AA28330@crltrx.crl.dec.com> To: video-mail@ATHENA.MIT.EDU Subject: Updating the architecture Cc: treese@crl.dec.com *** EOOH *** Date: Mon, 24 Apr 89 02:08:15 EDT From: treese@crl.dec.com (Win Treese) To: video-mail@ATHENA.MIT.EDU Subject: Updating the architecture Cc: treese@crl.dec.com Since I'll be out of town until Wednesday night, I won't have a new spec ready for the next meeting (at least, not in time for anyone to read it). If you can piece it together, the spec should be considered the current rev of the document, plus the decisions at the last meeting, plus my responses to Rob's and Don's mail. Please, please look it over in the next few days. I, for one, am going to implement to the spec that we have after debating it Thursday. - Win  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA11623; Mon, 24 Apr 89 01:53:01 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AB17165; Mon, 24 Apr 89 02:51:48 EDT Received: by MORPHEUS.MIT.EDU (5.45/4.7) id AA10997; Mon, 24 Apr 89 02:48:36 EDT Date: Mon, 24 Apr 89 02:48:36 EDT Message-Id: <8904240648.AA10997@MORPHEUS.MIT.EDU> To: maya@ATHENA.MIT.EDU Cc: alens@ATHENA.MIT.EDU In-Reply-To: 's message of Sun, 23 Apr 89 18:29:38 EDT <8904232229.AA04688@E40-115A-1.MIT.EDU> Subject: possible problem in move-to *** EOOH *** From: Date: Mon, 24 Apr 89 02:48:36 EDT To: maya@ATHENA.MIT.EDU Cc: alens@ATHENA.MIT.EDU In-Reply-To: 's message of Sun, 23 Apr 89 18:29:38 EDT <8904232229.AA04688@E40-115A-1.MIT.EDU> Subject: possible problem in move-to The %contains-word operator should work on words separated by any non-letter character (including symbols, spaces, or numbers). Please send an example if you find something that doesn't work. Jeff  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13569; Mon, 24 Apr 89 08:06:48 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA19459; Mon, 24 Apr 89 09:02:17 EDT Received: by FLOTSAM.MIT.EDU (5.45/4.8) id AA16602; Mon, 24 Apr 89 09:01:31 EDT From: Daniel I. Applebaum Message-Id: <8904241301.AA16602@FLOTSAM.MIT.EDU> To: video-mail@ATHENA.MIT.EDU Subject: free play Date: Mon, 24 Apr 89 08:01:29 EST *** EOOH *** From: Daniel I. Applebaum To: video-mail@ATHENA.MIT.EDU Subject: free play Date: Mon, 24 Apr 89 08:01:29 EST I don't like this idea of flexible start and end times for time slices. If you want such a feature, why not just have the scheduler tack on an extra 'n' seconds on the beginning and end of each slice. If you let Galatea be shoddy about checking, then you could get overlaps. Remember, if the client programs are written even half-competently, there should never be a time when Galatea refuses to do the request. Galatea's checking is only to prevent bugs. Our clocks had better be pretty well synced. Network delays won't affect this issue much because a delay near the start of a slice will only increase the chances of the request falling into the correct time. And if the request is made so close to the end of the slice that the network delay will force it outside, then that request wasn't going to be valid for long enough to be useful, anyway. Client programs are responsible for switching to another input source after their time slice is over. Dan.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA13826; Mon, 24 Apr 89 08:27:44 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA19810; Mon, 24 Apr 89 09:25:06 EDT Received: by FLOTSAM.MIT.EDU (5.45/4.8) id AA16661; Mon, 24 Apr 89 09:24:21 EDT From: Daniel I. Applebaum Message-Id: <8904241324.AA16661@FLOTSAM.MIT.EDU> To: video-mail@ATHENA.MIT.EDU Subject: Hey, check this out... Date: Mon, 24 Apr 89 08:24:17 EST *** EOOH *** From: Daniel I. Applebaum To: video-mail@ATHENA.MIT.EDU Subject: Hey, check this out... Date: Mon, 24 Apr 89 08:24:17 EST Time slice verification is being performed on the local (client) workstation, so the clocks are necessarily synced. Also, the "network" is a UNIX domain socket (assuming ULTRIX still supports those) so the network delays are going to be less than 1 sec. Now, why didn't I think of that? Dan.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA00376; Tue, 25 Apr 89 00:21:22 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA10698; Tue, 25 Apr 89 01:19:45 EDT Received: by PINK.MIT.EDU (5.45/4.7) id AA08859; Tue, 25 Apr 89 01:18:52 EDT Date: Tue, 25 Apr 89 01:18:52 EDT Message-Id: <8904250518.AA08859@PINK.MIT.EDU> To: video-mail@ATHENA.MIT.EDU Subject: Page 8, mail service *** EOOH *** From: Date: Tue, 25 Apr 89 01:18:52 EDT To: video-mail@ATHENA.MIT.EDU Subject: Page 8, mail service > Page 8, mail service: i think the system should automatically inc the guy's > mail at startup/login. i remember having the damnedest time understanding > what "inc" was for, and why it was necessary, when i came to athena from > a less aggressively-networked unix shop. it seems to me that it's not necessa ry > at the show, because the users' sessions provide only mail, anyway. * The only vestige of MH left at this point is the mail storage format (which * is very simple. I have been assuming that the UI will "do the right thing", *whether that turns out to be displaying new messages at login, or saying * "You have new mail. Click here to see it." * - Win Good questions. I'm unsure as to what the current mailer interface is for this. Is there an "inc" or equivelant? From my stand-point, I'd be just as happy to have mail automatically "inc"'ed at login. This brings up an interesting question, though...will anyone get mail *while* they are using Pygmalion and want to see it when it arrives? To date, the UI design expects not to deal with retrieving new mail. It is assuming that mail is already inc'ed into a folder at login or that it is being grabbed from the mail spool on a "as needed" type basis. We don't have a "Click here to see it" type button in any of our drawings at the moment. Though, this would be trivial to add, perhaps to the browser. (The browser is the part I've given the least attention to as far as in-depth thought. Win, I should probably speak to you about this and ask your thoughts on it.) -- Brian  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA00402; Tue, 25 Apr 89 00:24:47 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA10787; Tue, 25 Apr 89 01:23:44 EDT Received: by PINK.MIT.EDU (5.45/4.7) id AA08864; Tue, 25 Apr 89 01:22:52 EDT Date: Tue, 25 Apr 89 01:22:52 EDT Message-Id: <8904250522.AA08864@PINK.MIT.EDU> To: video-mail@ATHENA.MIT.EDU Subject: Request for help. *** EOOH *** From: Date: Tue, 25 Apr 89 01:22:52 EDT To: video-mail@ATHENA.MIT.EDU Subject: Request for help. If anyone has a chance, I'd really appreciate it if someone could go over the spec with me. (I'm afraid my reading speed is much too slow to read that many pages in time for the meeting.... Anyone willing to give a dyslexic a hand? Maybe a fellow UI person? ) -- Brian  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA05632; Tue, 25 Apr 89 11:24:25 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA19924; Tue, 25 Apr 89 12:24:16 EDT Received: from BUCSE.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA24970; Tue, 25 Apr 89 12:18:07 EDT Received: by bucse.bu.edu (5.31/4.7) id AA04063; Tue, 25 Apr 89 11:23:42 EST Date: Tue, 25 Apr 89 11:23:42 EST From: jbf@bu-cs.BU.EDU Message-Id: <8904251623.AA04063@bucse.bu.edu> To: huang%bucsf.BU.EDU@bu-it.bu.edu, rap@ATHENA.MIT.EDU, rap%bucsf.BU.EDU@bu-it.bu.edu Subject: Chip Bruce *** EOOH *** Date: Tue, 25 Apr 89 11:23:42 EST From: jbf@bu-cs.BU.EDU To: huang%bucsf.BU.EDU@bu-it.bu.edu, rap@ATHENA.MIT.EDU, rap%bucsf.BU.EDU@bu-it.bu.edu Subject: Chip Bruce Wed 4/26 5pm SED rm 250. This is a job talk for the Linguistics position in the School of Ed. Chip is a CS Ph.D. who has been working in Education at BBN.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA15681; Tue, 25 Apr 89 20:02:04 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA02008; Tue, 25 Apr 89 21:00:06 EDT Received: by TARTAROS.MIT.EDU (5.60/4.7) id AA22424; Tue, 25 Apr 89 20:59:57 EDT Date: Tue, 25 Apr 89 20:59:57 EDT Message-Id: <8904260059.AA22424@TARTAROS.MIT.EDU> To: video-mail@ATHENA.MIT.EDU Cc: copying@ATHENA.MIT.EDU, lvsd@ATHENA.MIT.EDU *** EOOH *** From: Date: Tue, 25 Apr 89 20:59:57 EDT To: video-mail@ATHENA.MIT.EDU Cc: copying@ATHENA.MIT.EDU, lvsd@ATHENA.MIT.EDU uh, ack isn't gonna like this, but i think the best way for messages to get fully duplicated across a logical volume is for the scheduler to handle it whenever the volume has two free disks. in any volume, even two disk volumes, this will occur frequently enough. but the scheduler will have to keep track of when to do this. -don  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA16319; Tue, 25 Apr 89 20:43:20 EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA02871; Tue, 25 Apr 89 21:43:15 EDT Received: from BUCSF.BU.EDU by bu-cs.BU.EDU (5.58/4.7) id AA04965; Tue, 25 Apr 89 21:42:33 EDT Received: by bucsf (4.12/4.7) id AA11650; Tue, 25 Apr 89 21:42:02 edt Date: Tue, 25 Apr 89 21:42:02 edt From: norsk%bucsf.BU.EDU@bu-cs.bu.edu (Ketil Hansen) Message-Id: <8904260142.AA11650@bucsf> To: RAP@ATHENA.MIT.EDU Subject: CALL VINC *** EOOH *** Date: Tue, 25 Apr 89 21:42:02 edt From: norsk%bucsf.BU.EDU@bu-cs.bu.edu (Ketil Hansen) To: RAP@ATHENA.MIT.EDU Subject: CALL VINC Hi Rich!! Vinc called. Somebody found your vallet. Call Vinc PH: 353-8964(school) or 787-9638(p) You father and mother has called to. see you later.  1,, Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA20141; Wed, 26 Apr 89 03:38:55 EST From: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA09313; Wed, 26 Apr 89 04:38:48 EDT Received: by E40-334-3.MIT.EDU (5.45/4.7) id AA00556; Wed, 26 Apr 89 04:38:39 EDT Date: Wed, 26 Apr 89 04:38:39 EDT Message-Id: <8904260838.AA00556@E40-334-3.MIT.EDU> To: jbf@bu-cs.bu.edu Cc: rap@ATHENA.MIT.EDU Subject: oral outline *** EOOH *** From: Date: Wed, 26 Apr 89 04:38:39 EDT To: jbf@bu-cs.bu.edu Cc: rap@ATHENA.MIT.EDU Subject: oral outline I hate to admit it but I need help on this outline. This is what I have so far. I also have a few other pages (at end); Scripts and GEMINI, GEMINI and SOPHIE, GEMINI and UC. I am trying to stay away from boring details, and just give overviews, lessons learned, and how to do it better. Ooops, forgot to spell check it before compiling, please disregaurd the spelling errors you will find. Please comment(!!). - Natural Language User Interfaces serve to translate natural text into some other representation. - Another application uses that representation to execute the user's command. - Knowledge about the domain has to be encoded into the translator. - Redundant encoding of knowledge into translator and applicator. Translator must know about concepts in the domain to parse correctly. The Semantic Units (SUs) - Are domain specific. - Each SU is designed to be autonomous. The designer should be able to concentrate on the defenition of one SU at a time and not worry about the rest of the system. - Contain all methods needed to create themselves and compare themselves. - Arranged in hierarchy with inheritance of any method. - Designed to match the sublanguage and not necessarilly the domain. The Parts of an SU - SU=< * class-name the name for this SU. * parent-name this SUs parent. * methods named list of methods such as fill-next-argument. * AS function Argument Sense function. The GASs of each of its arguments. * AC function Argument Class function. i.e. Required. * ANRL Argument Name Ranking List List of rules to rank arguments by name. * AMML Argument Method Modifier List List of rules to rank arguments by content. * C function Correlation function. > The Distributed Parser (DP) - Idea is to decentralize parsing. * To avoid ripple effect in modifying the semantic ATN. * To allow designer to concentrate on each SU at a time. - Parsing should be automated as much as possible. - Each SU is responsible to parse itself. - The DP is at least as powerfull as a more normal semantic ATN. How an SU participates in Distributed Parsing - SUs should define data which is easy for a native speaker to produce about a concept. - SUs are responsible to... * construct themselves from input and other SUIs. * recognize and adapt to special configurations of an SUI. - Key to the DP is the fill-args arc. - Fill-args is used to complete the defenition of an SUI. - Fill-args arc asks an SUI two questions... * can you use the next input symbol? * are you happy? - Creates a left to right bottom up parse. Defining an SU is Not Difficult - Designer defines the arguments an SUI can take. Defines... 1. names. Directly. (AS function) 2. types. Indirectly. 3. classes. Directly. (AC function) 4. methods to construct an argument from an SUI. - Number 4 requires formal means of communication amongst SUs. Area of concentrated future work. - Defining the arguments, their names, types, and classes is intuitive. - SU can use its own typed, named, and classed argument list to decide how to parse itself. Extending the DP Paradigm - To address flexibility in subnet design and left-right parsing problems... * Allow fill-args to finish without a complete SUI. * Once an initial parse is complete, to ask each SUI is parse to see if it can use the SUIs to the right of it. Repeating this creates a type of chart parser. - To address problems in constructing SUIs... * Formalize a means of extracting relevant information from an SUI. * Have SUs explicitly define types of argument lists and automatically parse from input. An SU (TOGGLE2> TV2 (scqm-fna toggle2-fna scqm-happy toggle2-happy) ( ((toggle between)) ) (-OBJ1- =OBJ= -OBJ2- =OBJ2= -IN- =IN=) (-OBJ1- R -OBJ2- R -IN- O) ( (t (raise all 5)) ) ( ((child-of -IN- ANOTHER-WINDOW) (raise -IN- 10)) ) (TOGGLE1> 0.9 ALL -1 VERB 0.2) ) ;-------------------------------------------------- (defun toggle2-fna (su-def * sentence frame ret node-name level) (let* ((su (car su-def)) (args (cdr su-def)) (arg1 (getf args '-OBJ1-)) (arg2 (getf args '-OBJ2-))) (cond ((not arg1) (cond ((ancestor-s 'BUFFER) (vals '-obj1- * ret)) ((ancestor-s 'MODE) (vals '-obj1- * ret))) ) ((not arg2) (if (not (ancestor-s 'TYPE)) (values 'atn 'CONJ/) (vals '-obj2- * ret))) ;; we do no checking here to make ;; that -obj2-is consistane with - ))) ;-------------------------------------------------- (defun toggle2-happy (su-def) (let* ((su (car su-def)) (args (cdr su-def)) (arg1 (getf args '-OBJ1-)) (arg2 (getf args '-OBJ2-))) (if (and arg1 arg2) su-def nil))) ;------------------------------------------------------------ (defun vals (arg-n * ret) (values t arg-n (binding-get-semcat (wordquark-proceeded-on *)) (ret-sentence-ptr ret))) Where the Answers Come From - The database is created by parsing old logs of the OLC. - The user's question is parsed, settled and then compared to each member in the database. - The highest ranked match is given as the users response. - There are no methods to aid in the search of the database. Depends on matching paradigm. Settling an SUI - Determines the importance of the arguments of an SUI. - Each component SUI is ranked according to how important its parent thinks it is. - An SUI ranks its arguments by name and content. - Ranking by name takes into account optional and modifier arguments. - Ranking by content takes into account special forms of the SUI. - Note how top-level SUI does not get ranked. - Rank of SUIs decreased as a function of their depth. - Need formal metrics for what ranks mean. Is arbitrary now. Comparing Two SUIs - Original process was flawed but informative. - Idea is that the correlation between two SUIs depends on how their SUs compare and how their arguments compare. - Uses information about the argument senses and argument classes. . .NOT FINISHED . --------------------------------------------------------------------------- SUPPLIMENTARY PAGES --------------------------------------------------------------------------- GEMINI and SCRIPTS - Scripts encode task specific information. - Scripts do not encode information about the concepts comprising tasks. - GEMINI does not encode task specific information but encodes concept specific information. - Answering questions about scripts requires comlpex matching and even theorom proving. UC, the Unix Consultant by R. Wilensky et. al. - Interface to static universe. - Uses PHRAN (PHRasal ANalyzer) to parse. - Represents commands as frames. - Frames are interpreted by rest of UC. - Frames are compositional by methods encoded into PHRAN. - Roles of frames are domain independant. SOPHIE system by Burton and Brown - Interface to dynamic universe. - Uses a semantic ATN. - Represents commands as procedures. - Procedures carry out the user's command. - Procedures are compositional by methods encoded in the specialists. - Encodes domain specific knowledge into specialists. - Specialis