Project Athena exists to deploy and maintain a campus-wide network of workstations and services (such as remote file access, printing, and electronic mail) to MIT for educational use. In addition to deploying workstations and linking them together with the network, Athena develops software of general use to the MIT community, for example new system services (such as the Zephyr notification service [DellaFera1988]), and educational software programs such as TODOR [Murman1988].
The turnin system is both a file exchange system service and educational software. It was developed in response to the request of MIT professors who wanted to use Athena to manage electronically submitted assignments. The first version supported student submission of assignments, and teacher return of annotated assignments or new files.
Subsequent versions offered more capabilities: real-time exchange of files in class, distribution of handouts, organization of papers to grade for the teacher, and integration of file exchange with document preparation.
This paper chronicles turnin from its beginning as a "silly little rsh script" to its present integrated application.
1 Version 1: "the rsh hack"
The first version of the turnin service had the least functionality, the worst user interface, and the most difficult set up process. It was first used in the early days of Athena before workstations were installed. At that time Athena consisted of 63 networked timesharing hosts.The path followed by student papers is shown in Figure 1. Files exchanged through turnin would start in the student's home directory on their assigned timesharing host. The turnin program would send the file over the net to a sub-directory associated with the course on the teacher's timesharing host. The teacher would find the file, probably move it to his or her home directory, manipulate it, (perhaps compile it, perhaps edit it), and then move it to the course's pickup subdirectory, where the student could find it when he or she ran the pickup program.
Figure 1: The Paper Path
1.1 Why not electronic mail?
Other communication services developed at Athena such as discuss [Raeburn1989], and Zephyr [DellaFera1988] were not implemented as electronic mail because they required services that electronic mail did not provide. (Instantaneous transmission in the case of Zephyr, and central sequenced storage of messages in the case of discuss.) With turnin, the primary issue was user interface.Professors wanted a user interface that more closely resembled the traditional "hand it in, mark it up, give it back" classroom process than existing exchange systems such as electronic mail and network filesystems did.
The service could be built on top of a network file system, the mailer, or any other available communication system as long as professors and students felt comfortable exchanging papers with it. For example, they didn't want to deal with mail headers in papers. In the simplest application, students would compose documents. These documents would be annotated by the teachers. The annotated documents would, probably, be re-used by the students for later drafts.
Some professors wanted to receive executable files to run rather than papers or program listings to read. This imposed the constraint that the transport mechanism be able to exactly reconstitute the bits of the submission, but even this was not necessarily difficult to do with an appropriate user interface to the mailer.
We decided against using the mailer because it was not well suited to use as a file repository. The Athena Post Office Service is based on the assumption that neither the mail hub nor the post office machines are used to store mail for long periods of time. They are configured for relatively small amounts of storage that is constantly reused.
1.2 The Student User Interface
Students were expected to use the UNIX timesharing host to do their work and exchange it with professors using these two commands:turnin problem_set file [file]
and
pickup [problem_set]
The problem_set argument was a string to name the problem set. Often this would be specified by the teacher. The file arguments could also be directories. If pickup were called with no argument or if the named problem set was not found, a list of existing problem sets to pickup was returned.
1.3 The Teacher Non-interface
The only professors who used turnin were UNIX cognoscenti or had teaching assistants who would do all the computer work for them. One course only used turnin as a way to collect assignments. A TA would send the assignments to the line printer and take the printouts to the grading meeting.To annotate files the teacher was expected to know the turnin file hierarchy and to use UNIX commands to obtain the file, edit it, and save the changed file in a similarly structured pickup hierarchy.
Here is an example of what the file hierarchy might look like for a course, say, intro with two students jack and jill:
intro/
TURNIN/
jack/
first/
README
foo.c
second/
Makefile
foo1.c
foo2.c
jill/
...
PICKUP/
jack/
first/
foo.errs
second/
a.out.errs
jill/
...
Organizing papers this way posed a problem. Most MIT professors are expert in their own fields, not in computers. Many found the hierarchy difficult to navigate and not well matched to their methods of organizing student work. This tended to make the teacher's job harder, while the goal of turnin had been to make it easier.
1.4 The Transport Mechanism
The first version of turnin relied on a primative mechanism for transfering data. Users of Berkeley UNIX may be familiar with the following command line to duplicate a hierarchy on a remote host:tar cf - | rsh remote.host "(cd destination/directory; tar xpBf -)"
On the timesharing host that was to receive papers, a special account called "grader" was created. Instead of /bin/csh like everyone else, grader's login shell was grader_tar. This program relied on receiving as arguments:
The grader.tar program relied on rsh for security. The turnin program would modify a .rhosts file in the student's home directory to allow the grader.tar's rsh to succeed. There was no global trusting among the timesharing hosts.
Probably the best enforcement of security came from the obscurity of the program. It was hard for the installers and developers to retain a clear idea of how it worked. This security through obscurity proved adequate for our prototype, but it was unacceptable for a turnin service in wide use.
The maintenance headaches came from teaching new people how to set up turnin, and in controlling the amount of disk taken up by the course. Setup required establishment of the grader account on the timesharing host, and installation of the user programs in course program libraries. The location of the course turnin directory had to be established and placed in a file along with the turnin program in the course program libraries. Athena User Accounts had to create a group for the graders, and keep it up to date. Student user id's had to be known to the course timesharing host, even if the students were not allowed to log on to it. Disk consumption had to be monitored by a person periodically running du over the course directory.
Usability was the biggest problem. A grader interface for those who were not UNIX literate was needed. It had to help rather than hinder the organizing of student files. The time delay in depositing files needed to be reduced. Other activities closely related to collecting and returning papers could also be supported.
The real reason why turnin version two came about, however, was the demise of the timesharing hosts, and the elimination of rsh as a transport mechanism.
The person assigned to do the new version of turnin was concurrently working with the MIT writing faculty on another project. He saw an opportunity to expand turnin; to market it to new users while at the same time completely re-implementing the old service. This follows the great MIT tradition, "We can't solve that problem, but we can solve another much harder problem."
The MIT writing faculty had formed a group, the Committee on Writing Instruction and Computers (known as CWIC, pronounced "quick"). This group met weekly to discuss ways that computers, specifically those offered by Athena, could be applied to improve writing instruction at MIT. This group came up with four basic activities of writing instruction they wanted the computer to support. In a writing class, students and teachers:
2. A Grade Sheet interface for assignments to provide a simple method for an instructor to organize and correct student assignments.
3. A Syllabus interface for handouts to organize these files in an easy to use format and to permit instructors to add or modify curricular files for in-class use.
4. A Turnin interface for turning in and picking up assignments and handouts. This interface simplifies current protocols for submitting assignments and picking up annotated papers or other class handouts.
5. An Electronic Textbook facility that permits the storage of a set of files representing class notes, instructions and other reference material.
6. A Presentation Facility to format files for display on a screen projection device, (i. e. Show the file on the workstation screen in a big font so it will be legible when displayed in class with a screen projection system.)
The files managed by the new version of turnin were organized into three classes:
It was initially unclear what sort of new transport mechanism was to be used in Athena's new distributed services environment. We decided not to use the mail system for reasons described above. Athena had recently deployed its discuss service [Raeburn1989]. We opted not to use the discuss protocol because generating lists of student papers would take a long time, all the papers would be kept in one large file, and utilities to allow old style UNIX command oriented manipulation would be hard to write.
We decided to access the server through a client library (which we named FX.) This would allow the same application programmers interface regardless of what transport mechanism we used. We expected to throw our first server away. We believed that the best way to offer the file exchange service was via a remote procedure call, much like the successful X server. We studied the Sun Remote Procedure Call system and felt it was the right implementation scheme, but were concerned that it would take too long to write and test such a server. As described below, we opted for a much simpler implementation strategy.
We agreed on the FX library calls by studying the spec and by designing the user programs. While Maria Camblor and I set about designing the server and implementing the client library, Rob Shaw and Bruce Lewis wrote the student programs and the teacher programs respectively. We documented our design for use by later developers [Camblor1988].
The teacher program was started once and had its own command parser. It enabled the teacher to create handouts, administer the class list, and to read, annotate, and return files.
There was a list of commands for each of the three functions:
grade: The trickiest part of using the grader program was in specifying files. If no files were specified, the program would assume that all were to be manipulated. To restrict operation the teacher would give a file specification with four parts separated by commas as the argument:
1. assignment number (abbreviated as) So commands like list taking a file name would have a reminder like this:
An empty field matched all, so
The administrative commands were installed to enable teachers to establish a class list. Only students in the class list were allowed to turn in or exchange files. The faculty found it inconvenient to maintain a class list on the computer, and the administrative commands were dropped from the grader program after a short amount of use. The actual workings of access control was de-coupled from the class list as described below.
The important functions were display, annotate, and return. The display command was used for showing files in class. It would fetch the specified file from the server and use a settable display program to view it. (e.g. more, vi or emacs) In practice a special emacs with a large font was used as the display program. The annotate and return functions were used to bring the turned-in file into an editor such as emacs and to return the modified file to the student. These commands were smart enough to be able to fetch and store multiple files.
We planned to implement access control lists, but abandoned them too due to lack of time and experience. Jon Rochlis looked at the old turnin hierarchy and suggested a way to use the standard UNIX file protection modes for access control. The method relied on the newly developed group access authentication that had been added as an Athena local change to NFS.
The NFS filesystems were organized as follows:
The file hierarchy looked like this (for a single student, wdc):
Using the clever NFS access modes, we wrote the server and FX client library in two weeks.
We met the user level spec with command line oriented programs: the familiar turnin and pickup. We added put and get for in-class file exchange, and take for teacher created handouts. Our crowning achievement was grade, a command oriented subsystem for finding new papers bringing them into an editor, and then returning modified papers.
The problems of setup and maintainability persisted. Controlling disk use became much more of a problem. The new problem of reliability arose: There was no graceful degradation of service in the face of NFS server failure. Disk usage had to be either monitored carefully, or had to have a lot of slack. If one student turned in enough to consume all the disk space, all courses using that NFS partition for turnin would be denied service.
Since the turnin file repository was a single directory hierarchy manipulated directly by the FX library, there was no mechanism for having secondary storage places if the course directory could not be written into. Even if secondary storage was available, no thought was given to merging primary and secondary storage places, nor to being able to tell when all storage places were accessible. If the one NFS directory was full, or if the particular server was down, that entire course was denied turnin service.
The turnin service put a strain on the Athena operations staff. The staff was only funded 9AM to 5 PM five days a week. Students would turn papers in 24 hours a day, seven days a week. If the NFS server went down, no paper could be turned in. In order for all courses to perceive turnin service to be working, all NFS servers holding turnin directories had to be working.
The reliability of the NFS based turnin system became difficult to maintain near the end of every term when the entire Athena system received its heaviest load. The turnin servers became heavily used with students turning in final papers, filling up the course directories when the operations staff is spread thin keeping the whole system up.
Our NFS servers used the Berkeley 4.3bsd quota system used to monitor disk consumption. This implementation of quota clashed with the mechanisms turnin used for access control. Since quota was by userid and since access was controlled by having students own their turned in files, quota would have to be set for each individual student. Professors found it onerous to use the grader tools to keep an on-line class list. Having to continuously advise Athena User Accounts of changes in the class was out of the question.
Creating a default quota for all students on a particular server would not have helped much. It would have been difficult to come up with a default number of disk blocks to allocate because some students were in more than one course, and some courses required bigger files than others. Although it would have solved the one failure mode mentioned above of one student denying turnin service, other modes of failure occurred more often. We never observed one student turning in a large block of files, but we often observed professors saving all student papers over a term and running the disk out of space.
Until some mechanism of group quota or access control by list rather than owner were developed, quota was disabled for course directories that used turnin. Someone on the Athena staff was assigned to watch over the disk usage.
We worked around disk space problems by spreading out course directories among several NFS servers, dedicating large partitions to the non-quota directories, and having one person spend a lot of time watching the disk usage. We tried to limit course directories to 50 meg in a term, and to keep in contact with professors so that they could delete files before space became a problem.
The new version had to retain or improve upon the previous version's functionality, security, and speed. For example, several courses were exchanging files in class in real time, and collecting handouts at the beginning of class. This real-time performance had to be retained.
The new version had to allow for easier server management. It had to allow:
The access control lists are maintained in a database under the control of the server. Previously, access control relied on the Athena method of creating credentials files which were updated nightly on all NFS servers. Intervention of Athena User Accounts and a significant time delay were required to offer turnin service to new courses, or to modify the list of qualified graders.
With the turnin server taking direct responsibility for access control, changes are made through simple applications, and take effect almost instantaneously. The head TA of a course can now add new graders. He or she needs no other special privileges or training. A new course can be created and used right away.
Having the server daemon own all the files is not a very good solution. If each course is arranged as a separate partition or volume, a quota for the daemon userid can be established. It would be a simple matter to make the server run setuid root and to be able to set the file ownership to a particular userid for quota purposes. Perhaps the best solution is to add quota management to the access control lists so that the quota establishment, too, can be an instantaneous process divorced from Athena User Accounts.
We made the following additional changes:
The basic operations were retained:
The database records information on the host responsible for holding the file, and there is a multi-server configuration that enables an authoritative database to be elected, and then shared among cooperating servers. The algorithms for electing and sharing are based on a simplification of the Ubik database system used in the Andrew Filesystem protection server.
These applications take advantage of the Andrew Toolkit (commonly called ATK) developed at Carnegie Mellon University [Palay1988]. ATK offers the following features which made it particularly useful in building grade and eos:
The multi-font text object was crucial. Virtually all multi-font text objects suitable for use as a stand alone text editor are extremely proprietary. We have not seen any other that has a code size under 1Meg. The ATK text editing objects are small, efficient, and extensible through the dynamic object loading system. We like being able to offer users the ability to edit equations, spreadsheets, and line drawings in eos without requiring all users to start up an eos containing all those subsystems. Until the time when students all run 12 MIP machines with 16 Meg of main memory, ATK offers an extremely attractive balance of size versus speed that no other toolkit has approached.
The original version of eos was done by N. Hagan Heller for her S. B. thesis at MIT in the department of Computer Science and Engineering [Heller1989]. She used the ATK Development Environment Workbench (ADEW) to do her prototype. The ADEW system allowed her to compose and modify her screen layout directly with a WYSIWYG interface. Although we opted to re-implement her prototype in raw ATK toolkit calls, we could have used the ADEW code generator to build the application. We chose not to use ADEW because of some restrictions that ADEW imposed which have, for the most part been removed. Nick Williams, of Imperial College, University of London, visiting MIT for the summer re-implemented Hagan's design with assistance from me. Nick's implementation is outlined in an EUUG talk [Williams1990].
The five student file exchange programs (turnin, pickup, put, get, and take), the editor, GNU Emacs, and the formatter (which was most often not used because it interfered too much with annotating) were made into an ATK editor with buttons across the top. Figure 2 shows eos with a typical short paper: The teacher interface, grade, looks just like the student interface except that the Turn In and Pick Up buttons are replaced with Grade and Return buttons.
The Guide button opens a window on an on-line style guide that is being experimented with by the writing teachers who use eos. It replaces a GNU Emacs based on-line style guide that was too hard to use. The new one uses hyper-link buttons to access a whole lattice of information. The Help button is used to start the ATK help documentation browser.
When a student clicks Turnin, a dialogue box pops up to get the filename and assignment number. The student is also given the choice of turning in the contents of the main editor window, or a file. In this way, users experienced with the old protocol of turning in a file will be able to use the new interface.
The Grade, Handouts and Exchange buttons all pop up a new window that contains a list of papers to select, along with appropriate operations to perform on the selected papers. For example, to annotate a paper turned in by a student, the teacher clicks the Grade button and positions the "Papers to Grade" window. Figure 3 shows a typical "Papers to Grade" window: The teacher clicks on the desired paper and then clicks the Edit button. The file is fetched from the turnin server into the main editor window of the grade program. The teacher then marks up the document. An object called note was developed for annotation. The ATK editor treats the note like a large character with internal state. When the note is closed, it appears as an icon of two little sheets of paper. When open, the text of the annotation is displayed. The user clicks on the icon to open the note, and on the black region at the top of the note to close it. Athena users of the ATK based editors such as eos, grade and ez, get the additional menu commands to create a new note, and to open and close all notes. When the teacher is finished modifying the file, he or she clicks the Return button, and the file is sent back to the turnin server for later Pick Up by the student. Figure 4 shows how a file with one open note, and two closed notes would look in a typical grade editor window: Although not shown in these basic demonstration figures, the ATK editor allows formatted text, and a rich variety of other types of data to be put in documents such as equations and line drawings. This capability will be exploited as more real-world documents such as proposals and articles are exchanged for annotation with turnin.
With the grade and eos applications, we finally realized the goal of enabling the teacher to point at papers on the screen, view them in final form, annotate them, and return them. The students are able to use the integrated system to receive the annotated papers, and use them directly for their next draft simply by deleting the annotations after reading them.
This summer we plan test turnin with simulated work loads of courses with 250 students in them. We hope to offer turnin this September as a replacement option for all courses presently using the NFS based turnin. Our development team has acquired a reputation for producing good software, so we expect that courses will be strongly encouraged to use the new turnin. We hope to phase out the NFS based turnin by the end of next academic year.
We will verify that our quota management procedures are workable. This will involve discussions with the operations staff to determine if separate volumes should be created or if the server should be changed to set a particular owner, or if it should enforce a quota itself.
Since the database is replicated, it should store a mapping of course name to a record of primary server and secondary servers. Then the FX library can contact any server for a list of the appropriate servers. The database can change the servers at any time. We initially expect a person to monitor the usage and adjust the database. In the far future heuristics to do load balancing automatically could be added.
We expect the user interface to continue to evolve into smoother integration with classroom procedures.
We would like to produce a set of interfaces for industrial use. The user paradigm would be documents cycling between author and either management or peers for review and revision.
The command line user interfaces would work, as is, on any UNIX platform that could accommodate a port of the FX library. It is possible that the WYSIWYG integrated interfaces could be ported to other platforms. Since the Andrew Toolkit has window system independent imaging model, a Presentation Manager, or Macintosh Toolbox based system could be produced with only moderate effort.
The FX client library could be converted back into a filesystem based back end for use on timesharing hosts, or other transport mechanisms could be used in place of Sun RPC.
We started with a simple user interface idea: exchange files as if they were papers passed around in class. We now have a body of knowledge about this application domain, and a body of code that implements several variations on this theme. A variety of interesting extensions can be made at comparatively low cost now that the basic work is done.
[Barrett1987] E. Barrett, F. Bequaert, J. Paradis, Electronic Classroom: Specification for a user interface, Athena Writing Project, Boston, MA, (4 June 1987) [Camblor1988] Maria Camblor, Rob Shaw, Bruce Lewis, William Cattey, File Exchange For The Educational On-Line System, Design Specification, Athena Writing Project, Boston, MA, (February 1988) [DellaFera1988] C. Anthony DellaFera, "The Zephyr Notification Service", Proceedings of the USENIX Winter Conference, pp. 213-219, USENIX Association, (February, 1988) [Dyer1988] Stephen P. Dyer, "The Hesiod Name Server", Proceedings of the USENIX Winter Conference, pp. 183-189, USENIX Association, (February, 1988)
[Heller1989} N. Hagan Heller, Designing a User Interface for the Educational On-line System, Massachusetts Institute of Technology, Boston, MA, May 1989 [Lewis,1989] B. R. Lewis, File Exchange Client Library, Massachusettes Institute of Technology, Boston, MA, (June 1989) {Murman1988] E. Murman, A. Lavin, S. Ellis, "Enhancing Fluid Mechanics Education with Workstation Based Software", AIAA 88-0001, (January 1988) [Palay1988] Andrew. J. Palay, Wilfred J. Hansesn, Mark Sherman, Maria G. Wadlow, Thomas P. Nuendorffer, Zalman Stern, Miles Bader, Thom Peters, "The Andrew Toolkit - An Overview", Proceedings of the USENIX Winter Conference, pp. 9-21, USENIX Association, (February, 1988) [Raeburn1989] Ken Raeburn, Jon Rochlis, Stan Zanarotti, William Sommerfeld, "Discuss: An Electronic Conferencing System for a Distributed Computing Environment", Proceedings of the USENIX Winter Conference, pp. 331-343, USENIX Association, (February, 1989) [Williams1990] Nick Williams, William Cattey, "The Educational On-Line System", Proceedings of the EUUG Spring Conference, EUUG, (April 1990)
It used this information to locate the files to transfer, and to set the student's host as the remote.host to rsh to. The turnin program would rsh -l grader passing it these arguments, and the grader_tar program would rsh back to the host that initiated the turnin to perform the transmission!
1.5 Security
Care was taken to prevent unauthorized access to turned-in files. The course turnin directory was accessible only to members of a file protection group which was specially made for each course, and to the magic grader account.
1.6 Problems
The turnin prototype was an interesting experiment in using the Athena timesharing hosts to exchange papers electronically, but as a service it left much to be desired. It had problems in setup, maintainability, and usability.
2 Version 2: Expanded Functionality
In spite of the problems with the user interface, turnin acquired a small but loyal following of satisfied customers. Athena decided to try and keep these customers when the timesharing model of computing was replaced with the distributed services model. Our challenge as turnin developers was to find a new file exchange mechanism not based on rsh that would work in the environment of non-secure workstations contacting secure service hosts.
A specification, Electronic Classroom: Specification for a User Interface [Barrett1987], was written based on the group's work. The second and third versions of turnin were based on this spec. Starting from the principle of computer enhancement of common activities in class, six components were called for:
Component number four represented a re-affirmation that the old turnin would be useful. The new version of turnin would implement as services the new components one, two, and three as well as re-implementing number four. The "Grade Sheet interface" of component two specified how organizing student papers would be improved for teachers not literate in UNIX.
The file exchange system was designed to support these and future classes of files so that user interfaces could be tailored to the kind of file being exchanged. The whole system of six components, and the procedures and protocols for applying them in the course of writing instruction were collectively called EOS the Educational On Line System.
2.1 Turnin on top of NFS
The spec was completed on 3 June 1987 and handed off to the development team. The team consisted of Maria Camblor, Bruce Lewis, and Rob Shaw with me as project manager. The timesharing model of computation at Athena was to be replaced by the distributed services model of computation on 1 September 1987. What sort of software could we offer as a robust implementation of the spec in three months, given that none of the team members had ever written a network service before?
2.2 The Clients
The student programs ended up resembling the original turnin programs. There were three major differences: Assignments were changed to be numbers rather than names. Teachers asked to organize papers by class week number. The course was specifiable by a command line argument and an environment variable. New commands were added for the two new classes of files. The student commands were:
get - fetch a file from the in-class bin of files to exchange
take - fetch a teacher created handout file
turnin - deliver assignment file
pickup - retrieve corrected assignment files
The student executed these programs from the shell when it was time to fetch or store a file.
list, l list files turned in
whois, who find a student's real name
display, show display a file
annotate, ann annotate a file
return, ret, r return annotated file to student
editor change or display current editor
purge, del, rm remove turned-in file from bins
man, info display information on a command
hand:
list, l list handouts
whatis, wha show note for a handout
put, p copy a file to a handout
note, n add a note to a handout
take, get, t copy a handout to a file
purge, del, rm remove handouts
admin:
add add a name
del delete a name
list, l list all names in course
The teacher would type the command and arguments. At any time the teacher could type "?" and get a list of the commands and a reminder of what the arguments were, or use the info command for more detailed information.
2. author user name (au)
3. version number (vs)
4. file name (fi)
list [as,au,vs,fi
]
list 1,wdc,,
would list all files turned in by user "wdc" for assignment 1.
2.3 The Server
We had insufficient time and experience to write a bona fide server. Instead, the client library attached an NFS filesystem, and implemented all the client calls as file operations. These NFS filesystems would be mounted when the application programs used the fx_open call to begin, and unmounted when the fx_close call was made, or when the program exited. This operation is consistent with operation of a network service.
This had the effect that students could not find out who else's files were on the server, they could only write files into the turnin directory, and would have trouble finding them to modify. They certainly could not read or modify other students files. The graders had free access to all the files. By attaching the course directory by hand, it was possible to create bogus turnin directories potentially locking out students. But the perpetrator would own the directories and could be traced.
total 4
-r--r--r-- 1 jfc coop 0 Aug 9 1988 EVERYONE
-rw-r--r-- 1 jfc coop 0 Aug 9 1988 List
drwxrwxrwt 2 jfc coop 512 Aug 9 1988 exchange
drwxrwxr-t 2 jfc coop 512 Jan 11 1989 handout
drwxrwx-wt 3 jfc coop 512 Aug 13 1988 pickup
drwxrwx-wt 3 jfc coop 512 Aug 9 1988 turnin
exchange:
total 0
handout:
total 23
-rw-rw-r-- 1 wdc coop 559 Jan 11 1989 1,wdc,0,avl.h
pickup:
total 1
drwxrwx--- 2 wdc coop 512 Jan 11 1989 wdc
pickup/wdc:
total 16
-rw-rw-rw- 1 wdc coop 1474 Aug 15 1988 1,wdc,0,bond.fnd
turnin:
total 1
drwxrwx--- 2 wdc coop 512 Jan 11 1989 wdc
turnin/wdc:
total 16
-rw-rw---- 1 wdc coop 1474 Aug 15 1988 1,wdc,0,bond.fnd
The class list (later abandoned) was kept in the file List. The existence of a file named EVERYONE signified that access was unrestricted. The owner of EVERYONE had to match the owner of the directory it was found in (to prevent just anyone from setting EVERYONE).
2.4 Problems
This version successfully addressed the problem of usability. The teacher input from CWIC enabled us to provide a better user interface, and enhanced functionality. Retaining the old hierarchy allowed teachers who were comfortable with UNIX to grade as they had in the past, by attaching the NFS course directory manually. The major usability problem remaining was the long time it took to generate lists of files. Since the files were spread across several directories, the FX library did the equivalent of a find to locate all the new files. The turnin suite of programs were, for the most part, simple, but could have been better integrated into the flow of the classroom. Typing commands could perhaps have been replaced by clicking the mouse.
3 Version 3: The Network Service
Whereas no more than 3 courses used the first version of turnin, a dozen used the second version and more were expected in the future. The service was proving useful and was expected to become popular. This meant that something had to be done to solve the operational problems. This stand-alone version was written by Rob French. Bruce Lewis, Clifford Tse, and I contributed.
We proposed to write a new back end for the FX client library that would meet these requirements.
3.1 The Server
The Sun Remote Procedure Call protocol was a commonly available mechanism for implementing a network service. Other protocols such as the Apollo Remote Procedure Call protocol could have been used. We chose Sun RPC because it was available, Rob had experience with it, and it seemed that its use was becoming more widespread.
Taking advantage of our experience, we changed the FX library a bit. Instead of storing an integer version number for the file, a hostname and timestamp were associated with it. This simplified establishing a version identity in an network of cooperating servers. Lists of files were returned as handles on linked lists rather than simple linked lists to ease storage management and passing of data over the network. We documented our new client library [Lewis1989].
The database is layered on ndbm. We rely on ndbm to allow an efficient scan of the entire database when we generate lists of files. Although a sequential scan of an entire database is slow, it is always faster than a find over a filesystem with the same number of nodes. So although this algorithm is slow, the perceived benefit is great. If very large courses are to be supported, this simple approach to database management can be replaced with a relational database which would allow matching on the various file parameters.
3.2 The latest user interface
The original file exchange service used the GNU Emacs text editor with additional commands for annotating and displaying texts. The latest user interface integrates displaying, editing, formatting, exchanging, and annotating into two applications: eos for the student, and grade for the teacher. The student application gets its name from the Educational Online System, the term coined for the suite of programs and protocols specified for supporting the classroom activities. Here at last is one program, containing all the pieces, worthy of the name of the whole system. The teacher program gets its name from the command oriented grader program of the previous version of turnin.
Nowadays many people are developing graphical applications. Developing X based applications with object oriented toolkits has become de regueur. Availability on the X tape allows more freedom than proprietary development platforms, and a rich selection of objects increases the likelihood that the developer can use existing toolkit code rather than writing new code.
Figure 2: Screen dump of EOS student interface.
Figure 3: Screen dump of "Papers to Grade" window
Figure 4: Screen dump of active grade window
3.3 Deployment Strategy
We are following a conservative path for migrating users to the new server. Although the greater maintainability is tempting, our first priority is reliable service. We decided to extensively test and experiment with the new version before getting rid of the old version. Consequently the new server and applications programs have only been in use by two classes of 25 students each for the past term. The single server configuration has been running for 94 days so far without crashing. Nobody has reported a single problem with server reliability. These two courses, however can be considered well behaved. One of the professors had extensive experience with the old turnin and never tries anything out of the ordinary. The two courses share the same teaching assistant who also had extensive experience with turnin.
4 Future directions
The present system allows storing files on secondary servers, identifying when all files are accessible, and merging in files from several places. It still has no provision for dividing work amongst servers in an equitable way. The list of servers to contact, and in what order is either registered with our Hesiod name server [Dyer1988] , or set in the FXPATH environment variable. This makes determining primary and secondary servers a very static process.
5 References