From savela@tel.vtt.fi Tue Aug 1 03:19:01 1989 Received: from santra.hut.fi by FLOTSAM.MIT.EDU (5.45/4.8) id AA25209; Tue, 1 Aug 89 03:19:01 EDT Received: from [130.188.1.1] by santra.hut.fi (5.61++/7.0/TeKoLa) id AA19814; Tue, 1 Aug 89 10:18:36 +0300 Received: by vtt.fi; id AA07673.R2.6; Tue, 1 Aug 89 10:03:07+0300 Date: Tue, 1 Aug 89 10:03:06+0300 Message-Id: <8908010603.AA07673@vtt.fi> From: savela@tel.vtt.fi (Markku Savela) To: "galatea-request@FLOTSAM.mit.edu"@YK.vtt.fi Subject: Live Digital Video in a Window Date sent: 1-AUG-1989 10:03:51 Hello, I'm mailing this to address "galatea-request@FLOTSAM.mit.edu" not really knowing whether it is the correct place. I have heard that there is already an old project implementing live video in windowing environment. I'm just asking whether any documentations or reports about the project is publicly available and references to them. Abstracts or short description of the project mailed to me would be enough for a start. I have information about similar things from Parallax and I guess the project may be somehow related, at least MIT is mentioned several times. I'm just expanding my knowledge about these things and trying to find out all the options and problems in using live video in windowing environment. thanks, -- Markku Savela | savela@tel.vtt.fi Technical Research Centre of Finland | savela%vtttel@router.funet.fi Telecommunications Laboratory | savela%vtt@finfun.bitnet Otakaari 7 B, SF-02150 ESPOO, Finland | From danapple Tue Aug 1 21:00:08 1989 Received: by FLOTSAM.MIT.EDU (5.45/4.8) id AA00350; Tue, 1 Aug 89 21:00:08 EDT From: Daniel I. Applebaum Message-Id: <8908020100.AA00350@FLOTSAM.MIT.EDU> To: savela@tel.vtt.fi (Markku Savela) Cc: galatea-request Subject: Re: Live Digital Video in a Window In-Reply-To: Your message of Tue, 01 Aug 89 10:03:06 P. <8908010603.AA07673@vtt.fi> Date: Tue, 01 Aug 89 21:00:04 EDT The live video in a window projects are mainly implemented using the Parallax 1280 and Parallax Viper graphics boards. If you have information from Parallax, then you know most of the info. The Parallax boards are capable of digitizing video directly into the frame buffer. MIT utilizes and works with Parallax in developing X11 software for using the Parallax. MIT mainly works on developing applications for using the technology developed by Parallax. The list you wrote to is mainly concerned with the status of Galatea, The Network Video Device Control System. I developed Galatea to use laser optical video disks in the X11/Video environment. If you are interested in video disks, let me know. If you're interested in video window products, get back in touch with Parallax, since they have one of the few products. Their address is Parallax Graphics, Inc. 2500 Condensa Street Santa Clara, CA 95051 (408)-727-2220 They have a version of X11 for their graphics processors. Dan. From danapple@flotsam.MIT.EDU Mon Apr 9 11:53:04 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA25251; Mon, 9 Apr 90 11:53:04 -0400 Received: from flotsam.mit.edu by ATHENA.MIT.EDU with SMTP id AA03909; Mon, 9 Apr 90 11:53:02 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA25245; Mon, 9 Apr 90 11:52:56 -0400 From: Daniel I. Applebaum Message-Id: <9004091552.AA25245@flotsam.MIT.EDU> To: Cc: galatea-request@ATHENA.MIT.EDU Subject: Re: Request for galatea-users subscription In-Reply-To: Your message of Fri, 06 Apr 90 11:16:00 -0500. <9004061516.AA17048@ATHENA.MIT.EDU> Date: Mon, 09 Apr 90 11:52:54 EDT Done. It's not a very active list yet, but based on the number of persons grabbing docs and distributions, it may become so, soon. Dan. From danapple@flotsam.MIT.EDU Mon Apr 9 11:54:26 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA25271; Mon, 9 Apr 90 11:54:26 -0400 Received: from flotsam.mit.edu by ATHENA.MIT.EDU with SMTP id AA03932; Mon, 9 Apr 90 11:54:21 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA25259; Mon, 9 Apr 90 11:54:08 -0400 From: Daniel I. Applebaum Message-Id: <9004091554.AA25259@flotsam.MIT.EDU> To: Tom Davidson Cc: galatea-request@ATHENA.MIT.EDU Subject: Re: Pls. add me to mailing lists. In-Reply-To: Your message of Mon, 09 Apr 90 09:04:51 -0500. <8a89O3X02QU1IfK3Va@foghorn.mpd> Date: Mon, 09 Apr 90 11:54:07 EDT Done. Note, they're not very active lists, but based on the number of persons grabbing docs and distibutions, they may become so soon. Dan. From danapple@flotsam.MIT.EDU Mon Apr 9 11:57:28 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA25295; Mon, 9 Apr 90 11:57:28 -0400 Received: from flotsam.mit.edu by ATHENA.MIT.EDU with SMTP id AA04043; Mon, 9 Apr 90 11:57:25 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA25282; Mon, 9 Apr 90 11:55:58 -0400 From: Daniel I. Applebaum Message-Id: <9004091555.AA25282@flotsam.MIT.EDU> To: galatea/pinewood_unix_hpopd////////HPMEXT1/galatea@hpopd.hp.com Cc: galatea-request@ATHENA.MIT.EDU Subject: Re: pls. add galatea@hpopdli.HP.COM to lists In-Reply-To: Your message of Mon, 09 Apr 90 12:06:37 -0000. <9004091106.AA16716@hpopd.hp.com> Date: Mon, 09 Apr 90 11:55:57 EDT Done. Note: they're not very active lists, but with the number of persons grabbing docs and distributions, they may become so, soon. Dan. From danapple@flotsam.MIT.EDU Mon Apr 9 19:47:25 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA25884; Mon, 9 Apr 90 19:47:25 -0400 Received: from flotsam.mit.edu by ATHENA.MIT.EDU with SMTP id AA19988; Mon, 9 Apr 90 19:47:23 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA25876; Mon, 9 Apr 90 19:47:06 -0400 From: Daniel I. Applebaum Message-Id: <9004092347.AA25876@flotsam.MIT.EDU> To: Winkler Cc: galatea-request@ATHENA.MIT.EDU Subject: Re: subscribe In-Reply-To: Your message of Mon, 09 Apr 90 14:11:46 -0400. <9004091811.AA02309@math.columbia.edu> Date: Mon, 09 Apr 90 19:47:04 EDT Done. Note: they're not very active lists, but with the number of persons grabbing docs and distributions, they may become so, soon. Dan. From djwalden@venera.isi.edu Mon Apr 9 19:54:16 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA25900; Mon, 9 Apr 90 19:54:16 -0400 Received: from venera.isi.edu by ATHENA.MIT.EDU with SMTP id AA20158; Mon, 9 Apr 90 19:54:12 EDT Posted-Date: Mon, 09 Apr 90 16:54:46 PDT Message-Id: <9004092354.AA07050@venera.isi.edu> Received: from gum.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Mon, 9 Apr 90 16:54:08 -0700 To: galatea-request@ATHENA.MIT.EDU Subject: mailing list Reply-To: djwalden@venera.isi.edu Date: Mon, 09 Apr 90 16:54:46 PDT From: Dave Walden Hello, Mail-lister: Would you please add me (Dave Walden, net adrs djwalden@isi.edu) to your Galatea mailing list. Thank you. Dave Walden djwalden@isi.edu From danapple@flotsam.MIT.EDU Tue Apr 10 15:42:29 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA27715; Tue, 10 Apr 90 15:42:29 -0400 Received: from flotsam.mit.edu by ATHENA.MIT.EDU with SMTP id AA16989; Tue, 10 Apr 90 15:42:27 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA27695; Tue, 10 Apr 90 15:41:57 -0400 From: Daniel I. Applebaum Message-Id: <9004101941.AA27695@flotsam.MIT.EDU> To: djwalden@venera.isi.edu Cc: galatea-request@ATHENA.MIT.EDU Subject: Re: mailing list In-Reply-To: Your message of Mon, 09 Apr 90 16:54:46 -0700. <9004092354.AA07050@venera.isi.edu> Date: Tue, 10 Apr 90 15:41:54 EDT Done. Note that the list is not very active, but with the number of persons grabbing the documentation and distribution, I hope that it will soon become so. Dan. From ang@theory.lcs.mit.edu Wed Apr 11 12:03:38 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA28749; Wed, 11 Apr 90 12:03:38 -0400 Received: from THEORY.LCS.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA13492; Wed, 11 Apr 90 12:03:36 EDT Received: by theory (4.0/TOC-1.2S) id AA12423; Wed, 11 Apr 90 12:03:29 EDT Date: Wed, 11 Apr 90 12:03:29 EDT From: ang@theory.lcs.mit.edu (William S. Ang) Message-Id: <9004111603.AA12423@theory> To: galatea-request@ATHENA.MIT.EDU Subject: add to mailing lists Please add me to both galatea-users and galatea-bugs list Thank you, William Ang ang@theory.lcs.mit.edu From danapple@flotsam.MIT.EDU Wed Apr 11 13:14:26 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA28904; Wed, 11 Apr 90 13:14:26 -0400 Received: from flotsam.mit.edu by ATHENA.MIT.EDU with SMTP id AA15752; Wed, 11 Apr 90 13:14:24 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA28900; Wed, 11 Apr 90 13:14:18 -0400 From: Daniel I. Applebaum Message-Id: <9004111714.AA28900@flotsam.MIT.EDU> To: ang@theory.lcs.mit.edu (William S. Ang) Cc: galatea-request@ATHENA.MIT.EDU Subject: Re: add to mailing lists In-Reply-To: Your message of Wed, 11 Apr 90 12:03:29 -0400. <9004111603.AA12423@theory> Date: Wed, 11 Apr 90 13:14:15 EDT Done. Note that these are not terribly busy lists, but with the number of persons grabbing the documentation and distribution, they may become so. Dan. From @mitvma.mit.edu:MP14STAF@MIAMIU.BITNET Thu Apr 12 11:07:56 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA29711; Thu, 12 Apr 90 11:07:56 -0400 Received: from MITVMA.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA15649; Thu, 12 Apr 90 11:07:55 EDT Message-Id: <9004121507.AA15649@ATHENA.MIT.EDU> Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 2372; Thu, 12 Apr 90 11:07:14 EDT Received: from MIAMIU.ACS.MUOHIO.EDU by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 4904; Thu, 12 Apr 90 11:07:13 EDT Received: from MIAMIU (MP14STAF) by MIAMIU.ACS.MUOHIO.EDU (Mailer R2.05) with BSMTP id 0658; Thu, 12 Apr 90 11:05:47 EST Date: Thu, 12 Apr 90 11:04:52 EST From: Mark Powers Subject: please sign me up To: galatea-request@ATHENA.MIT.EDU Please sign me up for the Galatea Users mailing list. Mark Powers Miami University Academic Computer Service From hawaii!odb.com!janet@uunet.UU.NET Thu Apr 12 12:07:55 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA29746; Thu, 12 Apr 90 12:07:55 -0400 Received: from uunet.UU.NET by ATHENA.MIT.EDU with SMTP id AA17534; Thu, 12 Apr 90 12:07:49 EDT Received: from hawaii.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA09708; Thu, 12 Apr 90 12:07:44 -0400 Received: by hawaii.odb.com (4.0/SMI-4.0) id AA12841; Thu, 12 Apr 90 09:25:04 EDT Date: Thu, 12 Apr 90 09:25:04 EDT From: janet@odb.com (Janet) Message-Id: <9004121325.AA12841@hawaii.odb.com> To: galatea-request@ATHENA.MIT.EDU Subject: Gatatea-users and release info Please add me to the Gatatea-users list, and send me info on the distribution. I have documentation from approx 1 yr ago. Thanks. janet@odb.com Object Databases 238 Broadway Cambridge, MA 02139 (617) 354 4220 * From danapple@flotsam.MIT.EDU Thu Apr 12 12:21:47 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA29810; Thu, 12 Apr 90 12:21:47 -0400 Received: from flotsam.mit.edu by ATHENA.MIT.EDU with SMTP id AA17899; Thu, 12 Apr 90 12:21:41 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA29803; Thu, 12 Apr 90 12:21:33 -0400 From: Daniel I. Applebaum Message-Id: <9004121621.AA29803@flotsam.MIT.EDU> To: Mark Powers Cc: galatea-request@ATHENA.MIT.EDU Subject: Re: please sign me up In-Reply-To: Your message of Thu, 12 Apr 90 11:04:52 -0500. <9004121507.AA15649@ATHENA.MIT.EDU> Date: Thu, 12 Apr 90 12:21:29 EDT Done. Note that this is not a very busy list, but it may become so soon. Dan. From danapple@flotsam.MIT.EDU Thu Apr 12 12:32:31 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA29868; Thu, 12 Apr 90 12:32:31 -0400 Received: from flotsam.mit.edu by ATHENA.MIT.EDU with SMTP id AA18359; Thu, 12 Apr 90 12:32:28 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA29860; Thu, 12 Apr 90 12:31:31 -0400 From: Daniel I. Applebaum Message-Id: <9004121631.AA29860@flotsam.MIT.EDU> To: janet@odb.com (Janet) Cc: galatea-request@ATHENA.MIT.EDU Subject: Re: Gatatea-users and release info In-Reply-To: Your message of Thu, 12 Apr 90 09:25:04 -0400. <9004121325.AA12841@hawaii.odb.com> Date: Thu, 12 Apr 90 12:31:29 EDT You've been added to galatea-users. The list isn't that busy, but since a lot of persons have been grabbing the documentation and/or distribution, it may become so, soon. I'm not sure what information you want. Do you want to grab a copy of the new documentation, or do you want me to send you an e-mail copy? If you want to grab either the doc or the distribution, anonymous ftp to flotsam.mit.edu (Internet 18.85.0.36) will let you grab either. Since I can't get a connection to odb.com, I'm guessing that you're not directly connected. If that's the case, I can mail you what you want. Documentation (PostScript or lineprinter?) or the entire release? Dan. From hawaii!odb.com!janet@uunet.UU.NET Fri Apr 13 00:35:51 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA01389; Fri, 13 Apr 90 00:35:51 -0400 Received: from uunet.UU.NET by ATHENA.MIT.EDU with SMTP id AA10502; Fri, 13 Apr 90 00:35:47 EDT Received: from hawaii.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA24796; Fri, 13 Apr 90 00:35:43 -0400 Received: by hawaii.odb.com (4.0/SMI-4.0) id AA14078; Thu, 12 Apr 90 18:26:40 EDT Date: Thu, 12 Apr 90 18:26:40 EDT From: janet@odb.com (Janet) Message-Id: <9004122226.AA14078@hawaii.odb.com> To: uunet!flotsam.MIT.EDU!danapple@uunet.UU.NET Cc: galatea-request@ATHENA.MIT.EDU In-Reply-To: Daniel I. Applebaum's message of Thu, 12 Apr 90 12:31:29 EDT <9004121631.AA29860@flotsam.MIT.EDU> Subject: Gatatea-users and release info Dave, I would like a copy of the new documentation. We are currently only a UUNET site, and do not have ftp abilities. So, if you could send it to me, via email i would appreciate it. Thanks -janet Gardner- janet@odb.com * From @IBM.COM:drake@almaden Fri Apr 13 16:07:49 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA01867; Fri, 13 Apr 90 16:07:49 -0400 Received: from ibm.com by ATHENA.MIT.EDU with SMTP id AA29002; Fri, 13 Apr 90 16:07:47 EDT Received: from almaden.ibm.com by IBM.COM (IBM VM SMTP R1.2.1MX) with BSMTP id 0637; Fri, 13 Apr 90 13:09:00 PDT Received: by sd2.almaden.ibm.com (AIX 2.1 2/4.03) id AA05672; Fri, 13 Apr 90 13:05:00 PDT Message-Id: <9004132005.AA05672@sd2.almaden.ibm.com> To: galatea-request@ATHENA.MIT.EDU Date: Fri, 13 Apr 90 13:04:39 -0800 From: "Sam Drake" Please register me with the mailing list. Thanks! From danapple@flotsam.MIT.EDU Sat Apr 14 12:30:22 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA02380; Sat, 14 Apr 90 12:30:22 -0400 Received: from FLOTSAM.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA15792; Sat, 14 Apr 90 12:30:07 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA02368; Sat, 14 Apr 90 12:28:31 -0400 From: Daniel I. Applebaum Message-Id: <9004141628.AA02368@flotsam.MIT.EDU> To: hawaii!janet@uunet.UU.NET (Janet) Cc: galatea-request@ATHENA.MIT.EDU Subject: Re: Gatatea-users and release info In-Reply-To: Your message of Thu, 12 Apr 90 18:26:40 -0400. <9004122226.AA14078@hawaii.odb.com> Date: Sat, 14 Apr 90 12:28:27 EDT Here is the lineprinter version of the documentation. The line after the dashes is the first line of the doc. It is blank since it is part of the title page. Dan. ---------- ___ _______ _______ _____ ______ _______ ______ THE Galatea NETWORK VIDEO DEVICE CONTROL SYSTEM ______ _ _________ Daniel I. Applebaum Massachusetts Institute of Technology M.I.T. Media Laboratory 20 Ames Street Cambridge, MA 02139 ________ ABSTRACT danapple@media-lab.media.mit.edu _______ Galatea is a network transparent video device control system, providing reliable access to various video devices in a distributed network environment without the need for complicated _______ client programs. This paper describes many features of Galatea, in addition to a description of the goals and strategies used in creating the system, and contains a manual for the C language programming interface. Copyright (C) 1990 Massachusetts Institute of Technology 1 _______________ Acknowledgments Several persons have helped in the development of Galatea. Each of their contributions is well appreciated. Hal Birkeland has made considerable improvements and fixes to much of the server implementation. The input of Ben Rubin and Paul Boutin has led to the implementation of many features in the current version. Patrick Purcell supported the early work on this system, from arranging for hardware, to consistantly pointing out bugs. Glorianna Davenport's constant encouragement and ideas were essential to the proper development of this system. Russ Sassnett provided most of the underlying device control system and device independant model for device control. These sections were part of an earlier project of his to provide network video device control. This project is supported by MIT Project Athena and the MIT Media Lab. 2 _ ____________ 1. Introduction _ _ ___________ _____ 1.1 Development Goals Galatea was originally conceived to support the Electronic Light Table project at the MIT Media Lab. This project was an application which permitted users to retrieve images from video disks into small on-screen "slides." The intended purpose of this application was to provide users throughout the MIT campus with a simple method to access a large central bank of image data. In order to control the centralized bank of video disk players, a client/server video control system was required. There were two such systems available for this purpose. One was created by Professor James Anderson of the MIT Architecture Department, the other by Russell Sassnett of MIT Film/Video. Although each of these systems provided most of the functionality required, neither could be used on a large enough scale to provide campus-wide distribution of video information. During the summer of 1988, development began on a network video device control system capable of being scaled for campus-wide use. Campus-wide use did not mean that the system would be deployed on many standalone computer systems, but that there would be many systems interacting and competing for access to distributed video resources. The resources devoted to serving the whole campus were a pair of Digital Equipment Corporation VDP50's video disk players and a BOA Source Controller II by Presentation Environments to switch the audio and video between the two players. These three units were controlled via RS232 by a DEC MicroVAX II which was connected to the campus computer 3 network. The output of the BOA video switcher was modulated and transmitted over the MIT cable system. Any location requiring access to the video disk players needed access to both the MIT cable system and the campus computer network. Additionally, it was common for a user's computer system to have its own local video resources. The "distributed" nature of the system stems from the need to control video devices on multiple computers without additional work by the user or the client applications. The results of these experiments with the centralized bank led to the development of the first version of Galatea. The style of the programming interface was designed to be similar to the C language interface for the X Window System. Since many applications using video in this environment were going to be created using X, creating a similar programming interface eased the programmers burden. Galatea is also intended to be a companion to X, and works very well in that environment, although only one sample Galatea application actually requires the presence of the X Window System. Galatea is available under the same copyright restrictions as X. A person may acquire all of the source code from publicly available sources, but must maintain the MIT copyright notice on all copies. _ _ ________ ___ ___ __ _______ 1.2 Features and Use of Galatea Galatea provides access to video devices in a distributed network environment. The system is designed in an enhanced client/server network model. A Galatea client, designed for a custom application, connects to a Galatea server on either the local or a remote machine. Once this connection is established, the client has access to the resources on the server. These can 4 include video disk players, uncontrolled input sources and video/audio switchers. The video/audio switchers are not referenced directly, but instead controlled by the server when the client requests access to video disks or uncontrolled inputs. ______ _____ A Volume Table maintained by the server describes which discs are in which players, how the signal sources are connected to the switches and how the switches are connected together to form a switching tree, terminating in a number of server virtual outputs. A single Galatea server can provide reliable access to many clients. The server dispatches on the incoming requests from clients, and guarantees each client a small time segment during which it has exclusive access. One client is not allowed to dominate the server, so that many clients and users can access a centralized bank of video resources without excessive delays. _ _ _ ________ ______ ______ _____ 1.2.1 Enhanced Client/Server Model To provide additional flexibility, a Galatea server can connect to another server and utilize the resources maintained there. Once this connection is established, the resources on the secondary server are considered equivalent to local resources, except for certain system maintentance purposes. This provides to a simple client application the ability to access video resources on multiple machines without having to connect to several servers. There is only one Galatea server ever on one machine (CPU). The servers maintain the forwarding capability and have automatic systems for dealing with system crashes and network failures. Typically, a Galatea server runs on all machines on which you wish to run a Galatea client, even if the 5 machine has no local resources. The local server has the responsibility of maintaining connections with the other remote servers. With this technique, a client program does not have to worry about a connection terminating if a remote machine crashes. The remote crash will be detected by the local server, which will then take appropriate action. Of course, a crash of the local server will bring down the client, but the local server should only crash if the entire machine goes down. _ _ _ ___ ______ _____ 1.2.2 The Volume Table A volume table is a list of video sources, each identified by name. A single volume does not necessarily correspond to a single video disk player or uncontrolled input channel. Multiple video disk players containing identical disks are combined into a single volume for client reference. Using this system, a client need only specify the name of the source that it wishes to access, and the server will deliver the video from the source most readily available. With this abstraction, there is no distinction made between resources on a local server and resources which are accessed through a chain of servers. On the other hand, the same video device can also be a part of multiple volumes. A single volume is associated with a specific server virtual output. Since a video device can be visible on several virtual outputs, it may be part of several volumes, each of which is associated with a single virtual output. There is no ambiguity here, since a client is only passed a list of volumes which correspond to a single output, so there are never multiple volumes of the same name and type associated with the same virtual output. There may be multiple 6 volumes with the same name if each volume is of a different type. The two types of volumes are record/play devices and uncontrolled input sources. _ _ _ ______ _______ _______ 1.2.3 Server Virtual Outputs A Galatea server is capable of serving multiple outputs, be they several channels on a cable television system or several displays on a single workstation. The identification of these outputs is site specific. In other words, the numbers used as identification for each output can be an arbitrary non-negative integer, in order to directly match cable channels or display numbers. These outputs are termed 'server virtual outputs' since their correspondence to physical devices is known only to the server, and this correspondence is specified in the configuration table. Each volume available on a server is tagged with a output number on which it is viewable. When a client connects to a server, it claims the ability to view one particular output. The client is then passed a list of volumes which are available on that output. A device which can be viewed on multiple outputs can be identified as having that capability in the configuration file. _ _ _______ _____________ _________ 1.3 Network Communication Protocols Galatea uses two forms of network communication to provide the reliability and flexibility necessary in a distributed network environment. The first level is a client to server protocol which utilizes TCP/IP as the transport layer. This level handles commands and requests to the server for device action or queries about device state. The other communication 7 level uses UDP transport layer for server to server communication to manage machine or network failure recovery. _ _ _ ______ __ ______ _____________ 1.3.1 Client to Server Communication The Galatea server initially creates a TCP/IP socket for listening to requests from clients for connections. This socket is bound to a well known TCP/IP port number, usually 4001. When a client requests a connection to this socket, the server accepts this connection request by creating another socket which is used to serve that client. The initial socket is ready to be used again for accepting connections from more clients. This methodology is almost universal among TCP/IP based servers. Once the client to server connection is established, the client may make requests to the server. The packet containing the request is structured. After the first request packet, the protocol is not clearly defined and can vary from command to command. The command request is defined by the following C language structure declaration. typedef struct { int parm[10]; } Galatea_packet; All of the integers in this packet are in network byte ordering, thus enabling hosts of different achitecture to communicate. The content of the first integer is defined to be a number indicating to the server what action should be performed. The server uses this number to branch to an appropriate routine to handle the rest of the command. The other integers in the packet are dependent on the particular command being executed. For example, many commands use the second integer to store the 8 volume identifier for a volume action request. If the command needs to send more data to the server than can fit in the initial command packet, additional data can be sent in a rather free-form manner. Strings and integers are passed as necessary for each command. Subroutines are provided to send and receive strings and integers. There are two modes for specifying responses from the server. In synchronous mode, most requests to the server are acknowledged by the server. The acknowledgment takes the form of a single integer, which is either a return value that the client requested, such as the current frame number on a device, or a value indicating an error. Values above 999,999 and below -999,999 are reserved for error values. Some commands, for instance a request for statistics about the server, will return much more information than just a single integer response. In some cases, however, it is advantageous for the return values from the server to be suppressed. This mode of operation is called asynchronous mode. Asynchronous mode is useful for _____ __________ video shuttlebar clients, which do not need responses to each request, and will operate faster if the client need not wait for the server responses. Requests which only query the server are usually not affected by asynchronous mode, since suppressing the returns in a query-only request is pointless. After a request is handled in synchronous mode, the server blocks operation until a release command is issued from the client. This gives the client a short amount of time in which to use the results of its request. For instance, after searching to a frame on a Record Play Device, a client may digitize the frame. 9 In order for this digitization to be reliable, the server must guarantee that no other client can manipulate any resource on the server during the digitization. Once the digitization is complete, the client sends the G_Release command to the server, freeing the server to accept commands from other clients. _ _ _ ______ __ ______ _____________ 1.3.2 Server to Server Communication The protocol for server to server communication is designed to compensate for machine and network failures. Normally, a server can connect to another server as a regular client. The server which is acting as a client is called a "client" server, and the server which is a server for a "client" server is a "serving" server. A "client" server makes one request that a normal client never makes. This is a G_RequestNotification request. When a server receives such a command, it places the network address of the requesting client in a file on disk. By placing this information directly to disk, the server guards against spontaneous machine crashes. Whenever a Galatea server rebuilds its internal volume table, it reads the list of hosts from disk, and notifies each host that it has rebuilt its volume table. The notification takes the form of a UDP packet containing the string "imhere". A server that receives such a UDP packet then rebuilds its own volume table. This technique propagates volume table rebuilds so that all of the servers which are affected by a change in device configuration have proper information. When a Galatea server is shut down, it also sends out a "imhere" packet, but then does not accept new connections. This action forces "client" servers to rebuild volume tables, but 10 since a connection can no longer be established to the "serving" server which is now shutdown, the "client" servers do not use any information about the devices on the now shutdown server. Since a Galatea server builds its volume tables when it is first started, it sends out a UDP "imhere" packet when it is first started. This causes any "client" servers which were using the "serving" server before the machine stop to establish new connections to the now running "serving" server. There is one common case which cannot be handled solely by "imhere" packets. This is where a network between two hosts fails, and the "client" server gets a network transmission or reception error. In this case, the "client" rebuilds its volume tables. While rebuilding, the "client" server will fail to connect to the "serving" server, and will not include the "server" server in the currently available volume table. When a "client" server fails to connect to a server, it establishes a pattern of sending query UDP packets to the server which was unavailable. These query packets contain the string "areyouthere". If a server receives a query packet, it sends an "imhere" to the host from which it received the "areyouthere" packet. This "imhere" packet will cause the querying server to rebuild its volume table, which should now include the previously unavailable server. 11 _ ____ _ ________ _________ ___ _______ 2. Glib - C Language Interface for Galatea This is a description of Glib, version 2.4. _ _ _______ _ _______ ______ 2.1 Opening a Galatea server The first operation a Galatea client needs to perform before making use of video resources on a server is establishing a connection to the server. The action is accomplished with or GNewOpenServer() or GOpenServer(): __________ Server *GNewOpenServer(hoststring) char *hoststring; __________ hoststring Specifies the name of the system which is running the Galatea server to which you wish to connect and the server virtual output number you wish to __________ use. The format for hoststring is ________ ______ "hostname:output" so that it closely matches the display name descrition in the X Window System. ____ If host is "" or "unix" Galatea will attempt to connect to a local server. GNewOpenServer() will eventually replace GOpenServer(). ____ _________ Server *GOpenServer(host, outputnum) char *host; int outputnum; ____ host Specifies the name of the system which is running the Galatea server to which you wish to connect. ____ If host is NULL or "unix" Galatea will attempt to connect to a local server. _________ outputnum Specifies the number of the server virtual output which the client wishes to use. A server which is used by several several workstations or several displays on the same workstation may define independent outputs for each unit. If a connection to the server cannot be established, a NULL is returned. Otherwise a legitimate connection has been 12 established, and the returned structure should be used in future Glib calls. _ _ _________ ___________ _____ ___ ______ 2.2 Obtaining information about the server Several subroutines are provided for obtaining information about the contents of the Server structure. Clients applications should use these routines for referencing the structure, and never attempt to modify it or inspect it directly. ______ int GNumberExtensions(server) Server *server; ______ server The server connection as returned by GOpenServer(). Returns the number of extensions that the server has available. Once this call is made, it is possible to interate down the list of extension names with the following command. ______ _____ char *GExtensionName(server, which) Server *server; int which; ______ server The server connection as returned by GOpenServer(). _____ which Specifies the position of an extension in the extension list. Returns a pointer to a private area which contains the _____ extension name of the extension at position which in the 13 extension list. ______ int GNumberVolumes(server) Server *server; ______ server The server connection as returned by GOpenServer(). Returns the number of volumes available on the server. The volume list is comprised of entries numbered from zero to the number of volumes minus one. After inquiring into how many volumes a server has, it is possible to interate down the volume list with the following three functions. ______ _____ char *GVolumeName(server, which) Server *server; int which; ______ server The server connection as returned by GOpenServer(). _____ which Specifies the position of a volume in the volume list. Returns a pointer to a private area which contains the _____ volume name of the volume at position which in the volume list. ______ _____ int GVolumeIndex(server, which) Server *server; int which; 14 ______ server The server connection as returned by GOpenServer(). _____ which Specifies the position of a volume in the volume list. _____ Returns the index number of the volume at position which in the volume list. ______ _____ int GVolumeType(server, which) Server *server; int which; ______ server The server connection as returned by GOpenServer(). _____ which Specifies the position of a volume in the volume list. _____ Returns the volume type of the volume at position which in the volume list. The volume type can be one of RPD_DEV or INPUT_DEV, specifying a "Record/Play Device" or uncontrolled "Input Device," respectively. ______ ______ ____ int GWhichVolumeIndex(server, volume_name) Server *server; char *volume_name; ______ server The server connection as returned by GOpenServer(). ______ ____ volume_name String containing the name of the volume whose index number you wish to obtain. Returns the index number of the specified volume on the 15 given server. This command allows a client which knows exactly which volume it needs to find the volume index number easily. The index number of a volume is used in all server action requests. ______ ___ char *GWhichVolumeName(server, ind) Server *server; int ind; ______ server The server connection as returned by GOpenServer(). ___ ind The index number of the volume whose name you wish to obtain. ___ Returns the name of the volume whose index is ind. This is the reverse function of GWhichVolumeIndex(). ______ int GMaxLockTime(server) Server *server; ______ server The server connection as returned by GOpenServer(). Returns the maximum time, in seconds, for which a client can acquire exclusive access to a server, either by a GLock() or by a GPlaySeg() in RETURN_SYNC mode. A lock which exceeds this time is silently broken by the server and the server will refuse to play a segment by GPlaySeg() which would exceed this time limit. A time limit of zero means that there is no limit on the length of a lock or segment. In a distributed environment, this is not 16 reliable, since remote locks may be broken earlier. ______ int GConnection(server) Server *server; ______ server The server connection as returned by GOpenServer(). Returns the connection number for the server. In UNIX, this is the file descriptor of the connection. _ _ _______ ___ ______ __________ 2.3 Closing the server connection Once the client is finished accessing the resources of a server, it may close the server connection with GCloseServer(). ______ GCloseServer(server) Server *server; ______ server The server connection as returned by GOpenServer(). GCloseServer() closes the connection to the server and frees all the data in the server structure. _ _ ___________ ___ ________ 2.4 Controlling the switches Once a server is opened and the client has determined which volumes are of interest, it is useful to set the server to display a particular volume of interest. The explicit switching command, GSwitch(), is used for this function: 17 ______ ___ ____ int GSwitch(server, ind, mask) Server *server; int ind; int mask; ______ server The server connection as returned by GOpenServer(). ___ ind The index number of the volume to which the switch should be made. ____ mask Bitwise or of one or more of LEFT_CHAN, RIGHT_CHAN, and VIDEO_CHAN, indicating which channel should be switched. GSwitch() commands the server to arrange for the volume indicated to become the current source for one or more of the signal channels. Servers can typically switch left audio, right audio, and video independantly, although the independance of the two audio channels is not guaranteed. AUDIO_CHAN can be used to indicate the bitwise or of LEFT_CHAN and RIGHT_CHAN, and ALL_CHAN can be used to indicate the bitwise or of LEFT_CHAN, RIGHT_CHAN and VIDEO_CHAN. Note that switching does not explicitly determine a particular switcher to affect, as the server may have to traverse a tree of switchers to accomplish the desired result. Only the desired volume is necessary. Many other commands can perform an implied switch for better performance. A switching mask is one of the parameters for those commands, for which a non-zero value indicates that switching should be performed. Using implied switching can increase speed of operation and reliable delivery. The only way to switch to an uncontrolled input source is GSwitch(), as none of the commands which implement an implied switch can operate on an uncontrolled 18 input. _ _ ____________ ____________ _____ _______ 2.5 Manipulating uncontrolled input sources As the name implies, there are no operations to be performed on an uncontrolled input source. The only command which can take the index number of an uncontrolled input source is the GSwitch() command, explained above. _ _ ____________ ______ ____ _______ 2.6 Manipulating record/play devices There are several methods of controlling a record/play device, ranging from variable speed play, single frame search to recording new frames. Several of these commands have a switching mask as an argument. When this mask is non-zero, it indicates to the server that after the requested operation is performed, a equivalent action to GSwitch() should be undertaken by the server. Therefore the end result of: GSearch(server, ind, 20000, ALL_CHAN); is the same as the result of: GSearch(server, ind, 20000, 0); GSwitch(server, ind, ALL_CHAN); The former will typically be a smoother and faster operation. Also, there is no chance that another client can access the server and disturb the arrangements in the first case, as can happen in the second. Only the results of a single command are guaranteed to be handled without another client interfering, unless GLock() is used to lock the server. The GRelease() command is used to indicate to the server that client 19 is finished with a particular request. When a request is made to a server, the server usually maintains the results of that request until the client calls GRelease(), or the server times out on the release. The client can indicate (with GSetState()) that an asynchronous mode should be used, in which the server does not maintain results. If the client issues another command, instead of a GRelease(), that command implies a GRelease() and the server then handles any other incoming requests, not necessarily the command that acted as a GRelease(). This algorithm ensures that a single client cannot dominate a server by simply sending a stream of commands without GRelease()'s. Additionally, servers typically time out on releases in five seconds in order to allow other requests to be processed. _ _ _ ________ ________ 2.6.1 Playback commands ______ ___ _____ ___ ____ int GSearch(server, ind, frame_num, mask) Server *server; int ind; int frame_num; int mask; ______ server The server connection as returned by GOpenServer(). ___ ind The index number of the volume on which you wish to search. _____ ___ frame_num The absolute frame number to which the volume should be searched. ____ mask A switching mask used for an implied switch. 20 GSearch() requests the server to search on the requested volume to the specified frame number. At the end of this operation, GSearch() returns the frame number which the volume is currently displaying. This command may not simply cause a search on a single video disk player. If multiple copies of a volume are available, the server will use the copy which will provide the fastest response time. This action is invisible to the client. After the search is complete, an implied switch is ____ performed, if mask is non-zero. ______ ___ _____ ____ int GRun(server, ind, speed, mask) Server *server; int ind; int speed; int mask; ______ server The server connection as returned by GOpenServer(). ___ ind The index number of the volume you wish to play. _____ speed The speed, in frames per second, at which the volume should be played. ____ mask A switching mask used for an implied switch. GRun() sets the requested volume in motion at the speed indicated. The speed is specified in frames per second, and the server will attempt as well as possible to match the requested speed. Not all players can play at an arbitrary frame rate. A closest match is attempted. The actual speed of playback is reported back to the client as the return value. The speed can 21 be positive or negative. The switching mask is handled as for GSearch(). The play continues until one of the ends of the disk is reached, or another motion command is executed. ______ ___ _________ ____ int GJog(server, ind, direction, mask) Server *server; int ind; int direction; int mask; ______ server The server connection as returned by GOpenServer(). ___ ind The index number of the volume you wish to jog. _________ direction The direction in which the volume should be jogged. ____ mask A switching mask used for an implied switch. A video jog is a single frame motion. This provides an easy way to step around a small portion of a video disk. The directions possible are FORWARD and REVERSE, only one of which may be specified. The new current position on the disk is returned. ______ ___ ____ int GStill(server, ind, mask) Server *server; int ind; int mask; 22 ______ server The server connection as returned by GOpenServer(). ___ ind The index number of the volume you wish to stop. ____ mask A switching mask used for an implied switch. To stop a running volume, use GStill(). The requested volume will be stopped and the current frame number of the volume will be returned to the client. ______ ___ _____ ___ _____ ____ int GPlaySeg(server, ind, start, end,speed, mask, ______ ____ return_flag) Server *server; int ind; int start; int end; int speed; int mask; int return_flag; ______ server The server connection as returned by GOpenServer(). ___ ind The index number of the volume you wish to play. _____ start The starting frame number from which the segment will be played. ___ end The ending frame number to which the segment will be played. _____ speed The speed at which the segment will be played. ____ mask A switching mask used for an implied switch. ______ ____ return_flag Value indicating whether the server should block until the end of the segment. 23 GPlaySeg() arranges to play a fully specified segment of video from a volume. The volume is first searched to the start frame, and playback is then assumed at the specified speed. Playback is stopped at the end frame. The implied switched in a GPlaySeg() is performed after the initial search and before the playback begins. Illegal combinations of frame numbers and ______ ____ speeds have unpredictable results. The return_flag indicates to the server whether to block until the segment is complete. A client may wish to block until a segment is complete, or it may wish to simply start the segment and let it progress, while returning the client to a running state. RETURN_NOW is the flag for starting the segment and then immediately returning control back to the client. RETURN_SYNC indicates to the server that the server should block until the segment is finished. Some servers may place a limit on the length of a segment requested with RETURN_SYNC, as such a segment might interfere with the operation of other clients. GPlaySeg() returns the frame number at which the server returned control to the client. This may be early in ___ the segment for a RETURN_NOW, and should be the end frame for a RETURN_SYNC. _ _ _ ______ ________ 2.6.2 Record commands Currently, recordable volumes are only considered recordable _______ by a Galatea server if the volume's device is local to the server. In other words, record requests cannot be forwarded. Also, volumes containing multiple devices are not ever _______ recordable. Galatea also assumes that recordable devices are write-once, not write-many. 24 ______ ___ _______ int GAlloc(server, ind, nframes) Server *server; int ind; int nframes; ______ server The server connection as returned by GOpenServer(). ___ ind The index number of the volume on which the allocation should be made. _______ nframes The number of frames requested in the allocation. _______ GAlloc() allocates nframes contiguous frames on the volume ___ indicated by ind. If the allocation succeeds, then the starting frame number of the allocated block is returned and the client may proceed to record onto any or all of the frames in the block. The allocation may fail because the device is not a recorder (FUNC_NOT_SUPPORTED), the device is too remote (FUNC_NOT_SUPPORTED), or the device does not have a sufficient number of free frames (COULDNT_ALLOC). ______ ___ _____ _______ int GAllocAtFrame(server, ind, start, nframes) Server *server; int ind; int start; int nframes; 25 ______ server The server connection as returned by GOpenServer(). ___ ind The index number of the volume on which the allocation should be made. _____ start The starting frame number for the requested block. _______ nframes The number of frames requested in the allocation. GAllocAtFrame() functions similarly to GAlloc() except that the allocated block will start with the frame number specified by _____ start. GAllocAtFrame() is useful when a recording is being continued from a previous session, and the new material must have a precise relationship to the previously recorded material. ______ ___ _____ _______ GFree(server, ind, start, nframes) Server *server; int ind; int start; int nframes; ______ server The server connection as returned by GOpenServer(). ___ ind The index number of the volume on which the allocation should be freed. _____ start The starting frame number to be freed. _______ nframes The number of frames requested to be freed. GFree() frees part or all of a previously allocated block, allocated by GAlloc() or GAllocAtFrame(). A client should only attempt to free frames which were not recorded. Frames that have been recorded can not be freed, since they will not be available for subsequent record operations. 26 ______ __________ _____ ___ _____ ____ GRecord(server, destvolume, start,end,speed, mask, ____________ ______ ____ sourcevolume,return_flag) Server *server; int destvolume; int start; int end; int speed; int mask; int sourcevolume; int return_flag; ______ server The server connection as returned by GOpenServer(). __________ destvolume The index number of the volume on which the recording should take place. _____ start The first frame on which recording should occur. ___ end The last frame on which recording should occur. _____ speed The speed at which the destination volume should record. (This paramter is currently ignored.) ____ mask A switching mask used for an implied switch. ____________ sourcevolume The index number of the volume from which the recording should take place. ______ ____ return_flag Value indicating whether the server should block until the end of the recorded segment. GRecord() records the video and audio from one volume onto a ____________ section of another volume. The sourcevolume may be either an _____ uncontrolled input or another record/play device. The start, 27 ___ _____ ____ ______ ____ end, speed, mask, and return_flag operate the same as in _____ ___ _____ ______ ____ GPlaySeg(). The start, end, speed, and return_flag parameters ____ affect only the destination volume. The mask parameter affects the routing between the source volume and the destination volume. Before recording takes place, the parameters are checked to make sure the recording can take place. Possible failures include BAD_VOLUME if either the source or destination volume is not valid, VIOLATE_ALLOC if the specified destination segment has not been previously allocated by the client, FUNC_NOT_SUPPORTED if the specified destination volume is not a recordable volume, COULDNT_ROUTE if the output of the source volume could not be patched to the input of the destination volume, COULDNT_DO_FUNC if the record command failed, and COULDNT_FREE if the segment was recorded correctly, but could not be removed from the allocation. ______ __________ ____________ ____ GRecordPreview(server, destvolume, sourcevolume,mask) Server *server; int destvolume; int sourcevolume; int mask; ______ server The Server connection as returned by GOpenServer(). __________ destvolume The index number of the volume on which the record preview should take place. ____ mask A switching mask used for an implied switch. ____________ sourcevolume The index number of the volume from which the record preview should take place. 28 GRecordPreview() allows the client to do all the routing associated with a GRecord() without actually performing the recording. The source volume is routed to the destination volume according the the switching mask and the destination volume device is placed into a record standby mode. This is useful to preview what the recording will look like, or to allow the destination volume to sync to the source volume. It may be necessary to position the destination to a recordable frame before this command is used, because some devices will not enter the record standby mode unless the device is positioned at an empty frame. The error COULDNT_DO_FUNC is returned if the record standby mode fails, possibly due to the device not being positioned at an empty frame. COULDNT_ROUTE is returned if the source volume could not be routed to the destination volume. _ _ _ _____ ______ __________ 2.6.3 Other device operations Other operations possible on a record/play device are changing the load state of the volume, changing the visibility of player frame index numbers, changing the audibility of the two audio channels, and getting the current frame number. ______ ___ __ ___ int GLoad(server, ind, on_off) Server *server; int ind; int on_off; ______ server The server connection as returned by 29 GOpenServer(). ___ ind The index number of the volume you wish to load. __ ___ on_off The new load state requested. GLoad() allows the client to manually load, unload or eject disks during runtime. This allows the user the change disks __ ___ dynamically for some applications. An on_off value of LOAD requests that the volume should be spun up, or loaded. A value of UNLOAD requests that the volume should be spun down, or unloaded. A value of EJECT requests that the disks be spun down and the disk player lids opened. If an EJECT request is sent, the Galatea will rebuild its volume tables, since a player with an open lid is not considered available. When a Galatea server is properly configured, changing the disks in a player where multiple copies of a disk exist may cause odd results, as the server assumes that all of the players contain the named disk. ______ ___ ____ __ ___ int GConfigure(server, ind, chan, on_off) Server *server; int ind; int chan; int on_off; ______ server The server connection as returned by GOpenServer(). ___ ind The index number of the volume whose configuration you wish to change. ____ chan Specifies the channel or channels whose configuration should be changed. __ ___ on_off The new configuration state requested. 30 When the client needs to change the audibility of the audio channels, or change the state of the frame index numbers, a call ____ to GConfigure() should be made for a specific volume. The chan parameter indicates whether the left audio channel, the right audio channel, or the index numbers should be changed by the __ bitwise or of LEFT_CHAN, RIGHT_CHAN and INDEX_CTRL. Any __ ___ combination of these may be specified. The on_off parameter indicates the desired state of the specified channel. Values of TURN_ON and TURN_OFF can be specified. ______ ___ int GGetFrame(server, ind) Server *server; int ind; ______ server The server connection as returned by GOpenServer(). ___ ind The index number of the volume whose current position you wish to obtain. GGetFrame() provides for the client to obtain the current position of a volume. If the user has searched maunally using GRun() commands for a particular frame, and now wishes to note the frame number, GGetFrame() can be used by the application to acquire that information. The current frame number is returned. _ _ _______ ______ _________ 2.7 Various server functions There are several server requests which do not specify or access particular resources on the server, but do control server behavior. 31 ______ int GRelease(server) Server *server; ______ server The server connection as returned by GOpenServer(). GRelease() releases the server from maintaining the results of the previous command. If the server is not maintaining results because the library is in ASYNC_MODE mode, this command has no effect. ______ int GLock(server) Server *server; ______ server The server connection as returned by GOpenServer(). GLock() establishes a temporary lock on all the resources of the server. This allows a client to be guaranteed of exclusive access to all resources on the server without other client interfering. These locks are typically limited in length by servers so that other clients are not permanently locked out of a server. Any other client that attempts to access the server during a locked period is simply blocked. If the locking client does not unlock the server before the time limit is reached, the lock is silently broken by the server. The maximum lock time is available with the GMaxLockTime() call. Using locks is encouraged for clients which need to ensure that a volume of 32 interest is completely set up for them for a short period of a time. Say, to GConfigure(), then GSearch(), then perform a still frame grab with an external processor, then unlock. GLock() is the only method to guarantee that no other client will intrude between the GConfigure() and the GSearch(). Also, if the frame grabbing board takes more time to grab than the standard release time, this mechanism provides for a slightly longer leeway after the GSearch(). (Caution: locks that must be forwarded between servers may provide less than the normal maximum lock time.) ______ int GUnlock(server) Server *server; ______ server The server connection as returned by GOpenServer(). GUnlock() unlocks a server which has been locked by GLock(). Clients are encouraged to unlock a server as soon as possible, in order to allow other clients access to server resources. ______ long GGetServerTime(server) Server *server; ______ server The server connection as returned by GOpenServer(). GGetServerTime() returns the current time on the server machine in seconds since midnight, January 1, 1970. This 33 information is useful in realizing volume scheduling systems. ______ ____ ______ GGetStatistics(server, stat_struct) Server *server; GStats *stat_struct; ______ server The server connection as returned by GOpenServer(). ____ ______ stat_struct A structure into which the server statistics will be placed. GGetStatistics() is used to get information regarding the server performance. The following structure is filled in: typedef struct { int revision; int num_requests; int run_time; int num_collisions; int num_connections; int max_connections; int delayed_requests; } GStats; ________ revision Indicates how many times the server has rebuilt its internal volume table. ___ ________ num_requests Specifies how many client requests have been made to the server. (Includes the current GGetStatistics() request.) ___ ____ run_time The number of seconds for which the server has been running. ___ __________ num_collisions The number of times two client requests have arrived at the server simultaneously. ___ ___________ num_connections The total number of connections made to the server. ___ ___________ max_connections The maximum number of simultaneous connections made to the server. _______ ________ delayed_requests The total number of client requests that were delayed because the server was busy processing another request. 34 ______ int GCheckRevision(server) Server *server; ______ server The server connection as returned by GOpenServer(). GCheckRevision() allows a client to manually check if its volume list (contained in the server structure) is up to date. Normally, an out of date volume list is indicated by the error message, VOLUME_LIST_OLD, returned by the server on most other commands. GCheckRevision() should only return NO_ERROR, VOLUME_LIST_OLD, or GIO_ERROR. NO_ERROR means that the client has an up to date volume list. VOLUME_LIST_OLD means that the client should get a new volume list with GReopenServer(). GIO_ERROR is encountered when a connection to a server dies. Unless a client is handling SIGPIPE's however, the SIG_PIPE will probably arrive first, and the client will exit. ______ Server *GReopenServer(server) Server *server; ______ server The server connection as returned by GOpenServer(). GReopenServer() is used by a client to obtain a new volume list, if the server indicates that the client has an out of date volume list. This situation can occur if a secondary server crashed, or comes on-line, and the primary server rebuilds its 35 internal volume tables to match the new availibilty of resources. A server can also be forced to rebuild its volumes tables by sending it a SIGHUP. GReopenServer() returns a pointer to a new server structure, or NULL, if there was some failure. ______ GRebuild(server) Server *server; ______ server The server connection as returned by GOpenServer(). GRebuild() simply requests that the specified server rebuild its volume table. ______ __ ____ GShutOff(server, up_down) Server *server; int up_down; ______ server The server connection as returned by GOpenServer(). __ ____ up_down An integer value indicating whether the server should leave the disks in a spun up or spun down state. GShutOff() requests that the server shut itself down, __ ____ possibly spinning down the disks first. An up_down value of SPINDOWN will make the server spin down the disks before exiting. A value of NOSPINDOWN will leave the disks in the spinning state when the server exits. 36 ______ ____ ____ ___ ____ GMount(server, disc_name, dev_name) Server *server; char *disc_name; char *dev_name; ______ server The server connection as returned by GOpenServer(). ____ ____ disc_name The name of the disc being placed in a device. ___ ____ dev_name The name of the device into which the specified disc is placed. GMount() allows a client program to indicate to the server that the contents of a device have been replaced with a new disc. ___ ____ dev_name is the name of the local device on which the new disc, ____ ____ disc_name is to be mounted. GMount() can only be performed by a client on the same host as the server, and only on a device local to that server. Once the mount is performed, the server rebuilds its volume table so that the mount takes place immediately. ______ ___ ____ GUmount(server, dev_name) Server *server; char *dev_name; ______ server The server connection as returned by GOpenServer(). ___ ____ dev_name The name of the device which is to be taken off-line. GUmount() is used to bring a local device, on the local server, off-line. The server immediately rebuilds its volume table, but ignores the now unmounted device. 37 ______ ___ ______ ____ _____ ___ _____ ____ GMounts(server, num_mounts, disc_names,dev_names, rets) Server *server; int num_mounts; char **disc_names; char **dev_names; int *rets; ______ server The server connection as returned by GOpenServer(). ___ ______ num_mounts The number of mount operations to perform. ____ _____ disc_names An array of disc names to be mounted. ___ _____ dev_names An array of device names to be mounted upon. ____ rets An array to contain the return values from each mount operation. GMounts() performs like GMount(), except that multiple mount operations are performed with a single request. The advantage of ___ ______ GMounts() is that num_mounts mounts can be performed with only a single ensuing volume table rebuild. If GMount() were called multiple times, a volume table rebuild would be performed for each call. Each mount performed by GMounts[] is comprised of a ____ _____ disc name from disc_names and the corresponding device name from ___ _____ ____ dev_names. The return value of each mount is placed in the rets array, which should have already been allocated by the client program. 38 ______ ___ _______ ___ _____ ____ GUmounts(server, num_umounts, dev_names,rets) Server *server; int num_umounts; char **dev_names; int *rets; ______ server The server connection as returned by GOpenServer(). ___ _______ num_umounts The number of unmount operations to perform. ___ _____ dev_names An array of device names to be unmounted. ____ rets An array to contain the return values from each unmount ___ _______ GUmounts() performs num_umounts unmount operations. The ___ _____ devices to be unmounted are specified in the dev_names array, and the return values from each unmount are placed in the ____ corresponding entry in the rets array, which should already have been allocated by the client program. Once all of the unmounts are accomplished, a volume table rebuild is performed. ______ ___ ______ _____ ____ _____ _____ GGetMounts(server, num_mounts, mount_devs,mount_discs) Server *server; int *num_mounts; char ***mount_devs; char ***mount_discs; ______ server The server connection as returned by GOpenServer(). 39 ___ ______ num_mounts Returns the number of mountable devices. _____ ____ mount_devs Returns the list of mountable devices. _____ _____ mount_discs Returns the list of discs mounted on the devices. GGetMounts() retrieves the list of mountable devices from the server, along with the currently mounted disc for each device. The number of mountable devices is returned in ___ ______ _____ ____ _____ _____ num_mounts, and the arrays mount_devs and mount_discs are allocated to accommodate the returned arrays. The client program must free the arrays when finished. If a device has nothing mounted, then the corresponding disc name is returned as [nothing]. ______ _____ GRequestNotification(server, yesno) Server *server; int yesno; ______ server The server connection as returned by GOpenServer(). _____ yesno An integer value indicating whether to enable notification. GRequestNotification() should never be used by an ordinary client. It is used by servers to request that other servers _____ notify them of volume table rebuilds. A yesno value of Notify indicates that notification to this host should be enabled; and value of NoNotify indicates that notification to this host should be disabled. Notification is only performed on a per-host basis, not on a per-client basis. The notification takes place over a UDP channel independent of the TCP connection used for normal communication. 40 _ _ ________ _____ ______ ___ ______ __ ___ _______ _______ 2.8 Routines which change the action of the Galatea library The Galatea library (Glib) can be set to act in several different modes. There are debug settings, timeouts, and asynchronous operation modes, as well as an error handling system. _____ ____ ___ ____ ___ ____ int GSetState(debug_mode, set_time, set_sync) int debug_mode; struct timeval *settime; int set_sync; _____ ____ debug_mode Specifies the new debug mode for library operation. ___ ____ set_time Specifies the new time out length on reads from the server. ___ ____ set_sync Specifies whether the library should act synchronously or asynchronously. GSetState() sets several modes of library operation. Debugging allows the library to print out some information as routines are called. This is mainly used in debugging the library, so the information printed may not be very consistent or useful. A value of one enables debugging and a value of zero disables debugging. The maximum time that the library will wait for a reply from ___ ____ the server can be set with the set_time argument. If NULL, the time out is infinite. Infinite is the default library time out. ___ ____ If set_time is non-NULL, the time contained in the timeval structure is copied and used for the new time out. The library can also be set to use asynchonous or 41 synchronous operation. Normally, all commands send a request to the server and then wait for a reply from the server indicating the request has been completed or that an error occured. This is called synchronous operation, since the client is kept synchronized to the server. For some applications, say a video shuttle control, acknowledgment of successful completetion is not necessary, since many commands are being sent, and single failures are not a problem. In the shuttle application, it is also unnecessary to wait for synchronization, and that wait can cause poor performance. For such applications, setting the ___ ____ set_sync argument to ASYNC_MODE will provide better performance. In this mode, many commands will report that no error occurred. For some commands, such as GReopenServer(), asynchronous mode is meaningless. Some other commands also act synchronously, even in ASYNC_MODE, such as GLock() and GCheckRevision(). The other change in ASYNC_MODE is that the server will not wait for a ___ ____ GRelease() from a client. A set_sync of SYNC_MODE returns the library to synchronized operation. _______ int GSetErrorHandler(handler) void (*handler)(Server *, int); _______ handler A handler procedure to be called when errors are reported by a server. Many Galatea commands can be met with an error response from the server. These errors are normally reported back to the client through the return value for the command. It is possible to intercept these error messages, and cause the library to 42 invoke a client specified error handler. A very useful error handler is one that can deal with a VOLUME_LIST_OLD error, execute a GReopenServer() and then update client structures or displays before returning. Such a system reduces code duplication. The command that caused the server still returns the error code, but the main sections of the client application _______ need not handle the error explicitly. A NULL for the handler procedure, causes the library to resume default action, which is to call GReopenServer() on the server which returned the error. This permits the following Galatea calls to procede normally. The arguments to the error handler are the server on which the error was generated and the error code returned by the server. The return value from the handler is not used. _ _ _____ ________ 2.9 Error messages Almost all Galatea library commands can cause an error to be generated on the server, if there is a fault in the function call or a device failure. The values returned are integers (32 bits). The return value of NO_ERROR is used to indicate simple completion of request which does not have an otherwise important return value. All of the actual error return values values have a value greater than or equal to LOWEST_ERROR. The actually error return codes are as follows: ______ ____ ___ VOLUME_LIST_OLD The volume list that the client is using is not up to date with the current version on the server. GReopenServer() should be called to get a new volume list. ___ ______ BAD_VOLUME The volume index number specified in the command is not a valid volume in the server. ____ ___ _________ FUNC_NOT_SUPPORTED An attempt was made to execute a function on a volume which cannot support the operation. An 43 example of this is trying to do a frame search on an uncontrolled input device. ___ _______ BAD_COMMAND The server was not able to interpret the request as a reasonable command. This is probably due to a mismatched library/server combination. _______ ______ COULDNT_SEARCH A device error was encountered while attempting to search on a record/play device. A retry may succeed. _______ ____ COULDNT_STOP A device error was encountered while attempting to stop a record/play device. A retry may succeed. _______ ______ _____ COULDNT_CHANGE_SPEED A device error was encountered while attempting to change the speed or direction of a record/play device. A retry may succeed. _______ __ ____ COULDNT_DO_FUNC A device error or internal server error was encountered while attemping an operation on any type of device. A retry may succeed. ___ ________ BAD_ARGUMENT An argument to a command was not valid. ___ _____ GIO_ERROR A server connection has been broken. This error indicates the the server to which the client is connected has crashed or been shutdown. If a client receives this error, it should not attempt to access the Galatea server again. _______ ___ ____ SEGMENT_TOO_LONG A segment requested in a GPlaySeg() or GRecord() exceeded the maximum lock time on the server. An attempt for the same segment in RETURN_NOW mode will probably succeed, but the segment may be interrupted. __________ ______ PERMISSION_DENIED An attempt to access a device or operation for which the user has insuffucient privleges was made. This includes attempting to load, unload, mount or unmount volumes on a remote host. _______ _____ COULDNT_ROUTE An attempt to switch either the viewable volume, or a recording cross-route failed due to a switcher error. A retry may succeed. _______ _____ COULDNT_ALLOC An attempt to allocated recordable frames failed. The recordable device has run out of available frames. This is analogous to malloc() returning NULL. _______ ____ COULDNT_FREE The server was unable to free the specified block. _______ _____ VIOLATE_ALLOC The client requested to record onto frames which are outside of any allocated segments. ___ ______ BAD_OUTPUT The client claimed to have access to a server virtual output which does not exist. 44 _ __________ _______ 3. Installing Galatea _ _ ___________ ___ ___________ _______ 3.1 Customizing the compilation process The Galatea distribution is setup to compile on a 4.3 BSD derived system. Without any changes, Galatea should compile on Ultrix, Sun OS, Athena UNIX, and 4.3 BSD. With minimal changes to the compile configuration file, it is possible to compile Galatea for HP-UX or Interactive 386/ix. To change the configuration to work on various systems, the file conf/config should be modified. This file contains a set of make(1) macro definitions that will be substituted into makefiles with the gconfig program, which is also in the conf directory. The conf/dirs file directs gconfig to the directories in which it should modify makefiles. To run gconfig, change working directories to conf 'cd conf', type 'make', then type 'gconfig'. When used without arguments, gconfig uses the config file to reconfigure the Galatea programs. If an alternate configuration file is required, type the name of the file as the first argument to gconfig, ie. 'gconfig hpux'. That invocation will use the hpux file as the template to configure Galatea for use on HP-UX hosts. If you wish to change the configuration parameters, edit the config file, or copy it, modify the copy, and invoke gconfig with your new file as the option. 45 _ _ ______ ______ __________ 3.2 Tuning server parameters There are several aspects of the server operation, mainly timing parameters, that can be adjusted for a particular site. All of these parameters are adjustable in the include file GALATEA/server/tunables.h The documentation for these parameters is in the include file. _ _ _________ ___ ______ 3.3 Compiling the system The Makefiles for Galatea are designed to compile the complete system without intervention. In the top level Galatea directory, typing 'make' should create the entire system. 'make install' will create the entire system, if necessary, and then install the executables, libraries and include files in common locations. This is normally /usr/local/{lib,include,bin} and /etc. If you wish to make these directories, 'make directories' will create any necessary directories that do not already exist. Typing 'make clean' will erase all of the object files and executables and typing 'make uninstall' will remove any installed files. _ _ ___ _____________ ____ 3.4 The configuration file The Galatea server uses a configuration file to determine what the devices are connected to the local machine, what remote servers are available, and the video connectivity of the site. Each line in the file specifies a directly connected device or a remote server. Fields which are meaningless for a given device type should be filled with ?. This configuration file is usually called /etc/galatead.conf 46 _ _ _ ____________ _ _____ _________ ______ 3.4.1 Representing a local videodisk player A directly connected videodisk player has a line with the following form: Type VolumeName Model TtyPort Baud Parity Chan The fields are separated by whitespace. The values for the fields are: Type This field should contain RPD, for Record/Play Device. VolumeName This field specifies the name of disk contained in the player. Model This field specifies the type of videodisk player. TtyPort This field specifies the port to which the videodisk player is connected. For a disk player connected to the serial port identified with _____ /dev/ttyS0, this field would be ttyS0. Baud This field specifies the baud rate for communication with the videodisk player. Parity This field specifies the parity for communication with the videodisk player. This field can be ____ ___ ___ ____ even, odd, any, or none. Chan This field specifies the switch and input to which the disk player connects. This field is comma separated list of items of the form x:n-m where n is the switcher number and m is the input _ _ number on the switch. 1-3 would represent switch 1, input 3. A special case for the switcher _ number is 0, which indicates that the disk player does not feed a switch, but is a direct server output. In this case, m is the server virtual output number. The x component of the item is _ _ optional and is either a o or i, standing for output or input. Note that if all the items in a single list must either all contain the x component, or they all must not contain that component. A device that is capable of recording _ can have a single item with an i for the x _ _ _ component. i:0-3 would indicate that the recording input of the RPD is fed from server virtual output number 3. 47 _ _ _ ____________ _ _____ _____ _______ ______ 3.4.2 Representing a local video routing switch The line of configuration for a local video switch has the following form: Type SWTR-n Model TtyPort Baud Parity Chan Aside from a few differences, the representation of a switch is identical to that of a videodisk player. If the field is not noted specifically below, use the description given for local videodisk player. Type For a local video switch, this field should be ____ SWTR. _ SWTR-n This field specifies the switch number. n should be the number assigned to the switch, which is used in referencing the switch in all other device representations. For configuration with a single switch, there could be one switch line ____ _ with SWTR-1 as the SWTR-n field, although the number chosen for the switch is arbitrary. Model This field specifies which type of switcher is connected. TtyPort Normally this field is the same as for an RPD, but certain switches can be chained together on a single serial port. For these switches, the TtyPort can be of the from x:m, where x is the device number in the chain and m is the port filename as for an RPD. Chan The channel description is a field made of a comma separated list of items of the form x:y;n-m The x component specifies which of possibly several physical switch outputs this item describes. This is used when you are configuring a multiple output switcher, such as the Akai 16x16 Digital Patch Panel. The y component indicates the default input which will be patched to the specified output. The output will be set to this input whenever the switcher is reset. Switchers are reset when the players are spun down, and when the volume table is rebuilt. The n and m components are as for an RPD where n indicates the switch to which the specified output is connected and m indicates to which channel on the next switcher the specified output _ is connected. A value of 0 for n indicates that the specified feeds a server virtual output and does not feed another switcher. 48 _ _ _ ____________ _ ______ ______ 3.4.3 Representing a remote server Any Galatea server can be configured to use the resources of another Galatea server. The local server incorporates the resources of the remote server as if they were located on the local host. Clients do not have any indication of differences between local and remote devices. To represent a remote server to the local server, use the following form of configuration file line: Type Hostname ? RemOut ? ? Chan ____ Type For a remote server, the Type should be FORW. Hostname This field specifies the hostname for the server to which the local server should connect. Remout This field specifies which of the outputs on the remote machine the local server should utilize. Chan This Chan field is almost identical to the Chan field for local video switches. The differences are that there is no default input for each output and that the output number specification is not important, except that each output number must be unique. So, the form of this field is a comma separated list of items of the form x:n-m. (A later version of Galatea will permit the ommision of the output number.) Of course, if you only have the forwarding device feeding one local input, you need not specify an output _ number. Again, if n is 0, then the forwarding device feeds a server virtual output. _ _ _ ____________ __ ____________ _____ 3.4.4 Representing an uncontrolled input A Galatea server can also make use of uncontrolled input sources, such as a camera. Such a device can be represented in the configuration file with a line of the form: Type InputName ? ? ? ? Chan _____ Type The Type should be INPUT for an uncontrolled input device. InputName This field specifies the name of the uncontrolled 49 input. Chan The Chan field is a comma separated list of items of the form n-m, where n is number of switcher to which the input is connected and m is the input channel number on the specified switch. If n is _ 0, then the uncontrolled input feeds a server virtual output. _ _ _ ______ _____________ _____ 3.4.5 Sample configuration files For a single disk player configuration: RPD BostonDisc SONY_LDP1000A ttyS0 4800 none 0-0 For a fairly complex configuration, with multiple switchers, multiple disk players, and a forwarding entry: # A line beginning with a # is a comment line. # This first group feeds the little switcher (SWTR-1) RPD BostonDisc SONY_LDP1000A ttyS1 4800 none o:1-1 INPUT MIT-CABLE ? ? ? ? 1-2 FORW flotsam ? 0 ? ? 1-2 INPUT ColorBars ? ? ? ? 1-3 # This device feeds the AKAI directly, and takes as its input # the 2nd output of the AKAI. RPD RECORDABLE PANA_3031F ttyS4 9600 none o:3-1,i:0-1 # The little switch feeds the AKAI, and the default input is # ColorBars SWTR SWTR-1 ATHENA_4x1 ttyS0 9600 none 1:3;3-2 # The big switch feeds virtual output 0 and 1, and has a # default input of SWTR-1, note the way the line is continued # on multiple lines. SWTR SWTR-2 AKAI16x16 0:ttyS3 19200 none 1:2;0-0,\ 2:2;0-1 i _____ __ ________ Table of Contents _ ____________ _ 1. Introduction 2 1.1 Development Goals 2 1.2 Features and Use of Galatea 3 1.2.1 Enhanced Client/Server Model 4 1.2.2 The Volume Table 5 1.2.3 Server Virtual Outputs 6 1.3 Network Communication Protocols 6 1.3.1 Client to Server Communication 7 1.3.2 Server to Server Communication 9 _ ____ _ ________ _________ ___ _______ __ 2. Glib - C Language Interface for Galatea 11 2.1 Opening a Galatea server 11 2.2 Obtaining information about the server 12 2.3 Closing the server connection 16 2.4 Controlling the switches 16 2.5 Manipulating uncontrolled input sources 18 2.6 Manipulating record/play devices 18 2.6.1 Playback commands 19 2.6.2 Record commands 23 2.6.3 Other device operations 28 2.7 Various server functions 30 2.8 Routines which change the action of the Galatea 40 library 2.9 Error messages 42 _ __________ _______ __ 3. Installing Galatea 44 3.1 Customizing the compilation process 44 3.2 Tuning server parameters 45 3.3 Compiling the system 45 3.4 The configuration file 45 3.4.1 Representing a local videodisk player 46 3.4.2 Representing a local video routing switch 47 3.4.3 Representing a remote server 48 3.4.4 Representing an uncontrolled input 48 3.4.5 Sample configuration files 49 From danapple@flotsam.MIT.EDU Sat Apr 14 12:35:55 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA02432; Sat, 14 Apr 90 12:35:55 -0400 Received: from FLOTSAM.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA15889; Sat, 14 Apr 90 12:35:53 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA02400; Sat, 14 Apr 90 12:33:19 -0400 From: Daniel I. Applebaum Message-Id: <9004141633.AA02400@flotsam.MIT.EDU> To: "Sam Drake" Cc: galatea-request@ATHENA.MIT.EDU In-Reply-To: Your message of Fri, 13 Apr 90 13:04:39 -0800. <9004132005.AA05672@sd2.almaden.ibm.com> Date: Sat, 14 Apr 90 12:33:18 EDT Done. Note that this is not a very busy list, but may become so as there are a growing number of Galatea users. Dan. From menga@cli52ch.edf.fr Tue Apr 17 14:11:00 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA20725; Tue, 17 Apr 90 14:11:00 -0400 Received: from inria.inria.fr by ATHENA.MIT.EDU with SMTP id AA24492; Tue, 17 Apr 90 14:10:54 EDT Received: by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA13042; Tue, 17 Apr 90 20:10:36 +0200 (MET) Received: from cli52ch. by edfder1.edf.fr, Tue, 17 Apr 90 13:43:13 +0200 Received: by cli52ch. (4.0/SMI-4.0) id AA07206; Tue, 17 Apr 90 14:56:41 +0200 From: menga@cli52ch.edf.fr (..David Menga N006 p.5508) Message-Id: <9004171256.AA07206@cli52ch.> Subject: Galatea Distribution and documentation To: galatea-request@ATHENA.MIT.EDU Date: Tue, 17 Apr 90 14:56:41 MET DST X-Mailer: ELM [version 2.2 PL0] Please, would you send me by e-mail all the Galatea distribution and documentation . Distribution could be sent using tar, compress and uuencode (or btoa) utilitaries , and broken into 32k pieces . No problem for Postscript interpretation . My e-mail adress is : menga@cli52ch.edf.fr . Thanks a lot ! Another request : Please, add me to your mailing list . Secondly , What about X Window Software for Interactive Video ? David Menga Software Engineer EDF - DER FRANCE From danapple@flotsam.MIT.EDU Wed Apr 18 18:34:45 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA23199; Wed, 18 Apr 90 18:34:45 -0400 Received: from FLOTSAM.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA06942; Wed, 18 Apr 90 18:34:34 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA23179; Wed, 18 Apr 90 18:34:22 -0400 From: Daniel I. Applebaum Message-Id: <9004182234.AA23179@flotsam.MIT.EDU> To: menga@cli52ch.edf.fr (..David Menga N006 p.5508) Cc: galatea-request@ATHENA.MIT.EDU Subject: Re: Galatea Distribution and documentation In-Reply-To: Your message of Tue, 17 Apr 90 14:56:41 +0700. <9004171256.AA07206@cli52ch.> Date: Wed, 18 Apr 90 18:34:14 EDT You have been added to thte galatea-users mailing list. This is not a very active list, but if a lot of persons start using Galatea, it may become so. Galatea contains one example of an X program for using interactive video. I have done other work with video for image archives under X. There is a proposed extension for dealing with video under X. To get on that list, send mail to xvideo-request@expo.lcs.mit.edu What else do you want to know? Dan. From freitas@3d.enet.dec.com Fri Apr 20 16:14:45 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA26137; Fri, 20 Apr 90 16:14:45 -0400 Received: from decwrl.dec.com by ATHENA.MIT.EDU with SMTP id AA11990; Fri, 20 Apr 90 16:14:42 EDT Received: by decwrl.dec.com; id AA09647; Fri, 20 Apr 90 11:11:24 -0700 Message-Id: <9004201811.AA09647@decwrl.dec.com> Received: from 3d.enet; by decwrl.enet; Fri, 20 Apr 90 11:11:46 PDT Date: Fri, 20 Apr 90 11:11:46 PDT From: 20-Apr-1990 1400 To: galatea-request@ATHENA.MIT.EDU Cc: freitas@decwrl.dec.com Subject: Please put me on the Galatea mailing list Hello, I work with Dave Carver (Project Athena), porting the Muse authoring system to DEC's DS5000 workstation. Along with other things, I will be porting and using Galatea V2.4 as the video server for our system. Please add me to the users list and the bug report list. Thanks! John Freitas (DECWRL::3D::FREITAS) (508) 493-6420 From danapple@flotsam.MIT.EDU Fri Apr 20 22:50:26 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA26453; Fri, 20 Apr 90 22:50:26 -0400 Received: from FLOTSAM.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA21452; Fri, 20 Apr 90 22:50:23 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA26442; Fri, 20 Apr 90 22:49:18 -0400 From: Daniel I. Applebaum Message-Id: <9004210249.AA26442@flotsam.MIT.EDU> To: freitas@3d.enet.dec.com Cc: galatea-request@ATHENA.MIT.EDU, freitas@decwrl.dec.com Subject: Re: Please put me on the Galatea mailing list In-Reply-To: Your message of Fri, 20 Apr 90 11:11:46 -0700. <9004201811.AA09647@decwrl.dec.com> Date: Fri, 20 Apr 90 22:49:16 EDT Done. Neither list is very active, but with the number of persons starting to use Galatea, they may become so, soon. Good luck with the port to the DS5000. Is that running Ultrix? If so, you should have little to no trouble. Dan. From danapple@flotsam.MIT.EDU Fri Apr 20 23:02:01 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA26515; Fri, 20 Apr 90 23:02:01 -0400 Received: from FLOTSAM.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA21847; Fri, 20 Apr 90 23:01:57 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA26513; Fri, 20 Apr 90 23:01:43 -0400 From: Daniel I. Applebaum Message-Id: <9004210301.AA26513@flotsam.MIT.EDU> To: freitas%3d.enet.dec.com@decwrl.dec.com Cc: galatea-request@ATHENA.MIT.EDU Subject: Re: Please put me on the Galatea mailing list In-Reply-To: Your message of Fri, 20 Apr 90 11:11:46 -0700. <9004201811.AA09647@decwrl.dec.com> Date: Fri, 20 Apr 90 23:01:42 EDT Done. Neither list is very active, but with the number of persons starting to use Galatea, they may become so, soon. Good luck with the port to the DS5000. Is that running Ultrix? If so, you should have little to no trouble. Dan. From grossman@oscar.tn.cornell.edu Mon Apr 30 22:06:14 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA16923; Mon, 30 Apr 90 22:06:14 -0400 Received: from OSCAR.TN.CORNELL.EDU by ATHENA.MIT.EDU with SMTP id AA04541; Mon, 30 Apr 90 22:06:11 EDT Received: by oscar.tn.cornell.edu (AIX 2.1 2/Dec 4 1989) id AA01074; Mon, 30 Apr 90 22:03:00 EDT From: grossman@oscar.tn.cornell.edu (David Grossman) Message-Id: <9005010203.AA01074@oscar.tn.cornell.edu> Subject: mailing list To: galatea-request@ATHENA.MIT.EDU Date: Mon, 30 Apr 90 22:02:59 EDT Please add me to the galatea mailing list. -- David Grossman grossman@tcgould.tn.cornell.edu From danapple@flotsam.MIT.EDU Tue May 1 20:45:40 1990 Received: from ATHENA.MIT.EDU by flotsam.MIT.EDU (5.61/4.8) id AA18713; Tue, 1 May 90 20:45:40 -0400 Received: from flotsam.mit.edu by ATHENA.MIT.EDU with SMTP id AA06826; Tue, 1 May 90 20:45:37 EDT Received: by flotsam.MIT.EDU (5.61/4.8) id AA18696; Tue, 1 May 90 20:44:44 -0400 From: Daniel I. Applebaum Message-Id: <9005020044.AA18696@flotsam.MIT.EDU> To: grossman@oscar.tn.cornell.edu (David Grossman) Cc: galatea-request@ATHENA.MIT.EDU Subject: Re: mailing list In-Reply-To: Your message of Mon, 30 Apr 90 22:02:59 -0400. <9005010203.AA01074@oscar.tn.cornell.edu> Date: Tue, 01 May 90 20:44:42 EDT Done. It is not a very busy list, but I'm hoping that soon it will become so. Dan.