GAPS: The Graduate Applications Processing System

by P. Gburzynski

GAPS is a web database for storing applications for graduate studies in Computing Science at the University of Alberta. The database can be accessed by the applicants, who can initiate their files and update their contents as new information becomes available, by the graduate committee members, who can also modify information in applicants' files (including some information not available to the applicants), and by faculty members, who can browse through the files and add their comments. I have tried to include in the functionality of this simple package most of the operations that we (the committee) would find useful. In particular, it is possible to upload (and view) images (GIF, JPEG), e.g., containing scanned transcripts or reference letters, as well as PDF documents. GAPS has been in operation since September 1998, and it has evolved quite a bit since then. It appears to be stable, secure, and foolproof.

Owing to the fact that applicants connect to us from many places around the globe, GAPS assumes a reasonably low common denominator for the web browser. In particular, it doesn't use JavaScript or frames. Having multiple versions of the forms (frames versus no frames, JavaScript versus no JavaScript) is out of the question because of the maintenance cost. Although the system allows the applicants to upload documents (which feature is only available in reasonably recent versions of Netscape and Internet Explorer), they are not required to use it.

GAPS has been implemented entirely in a scripting environment, using a generic FORMS server based on SICLE -- courtesy of appHome, Inc, which (believe it or not) is the most recent incarnation of SMURPH combined with Tcl. The GAPS server is not meant to cater to thousands of clients at the same time, but it can reasonably well process a few users (sessions) in parallel. Besides, the server is scalable, in the sense that multiple copies of it can be run concurrently (possibly on different machines), as long as the machines use the same file system accessible via NFS. In the current "production" version of the system, there are three copies of the server: two copies handling requests from the world, and one copy reserved for the committee and faculty at our department.

GAPS is not a completely trivial web application because it needs the notion of a "session" consisting of a sequence of related web transactions. To access the database, you need a username and password. There are four types (classes) of users:


Every applicant selects a user name and password that will grant them access to their file. This is done automatically without our intervention. In fact, the APPLICANT class consists of a number of subclasses, each subclass corresponding to a given academic year. Besides selecting a user name and password, the applicant must also decide on the academic year for which the application will be submitted. User names are local with respect to the year.


Every graduate committee member receives a username and password identical to their UNIX username and password. This kind of account grants unlimited access to all files and their contents.


All faculty members (not serving on the graduate committee) receive FACULTY-class accounts (with their UNIX usernames and passwords) so that they can look at the files whenever they please. FACULTY-class users can look at the files, but they cannot modify them, except for adding comments (that the committee can read).


This user is in charge of database maintenance, adding and removing users, etc. It is possible to have multiple users with these privileges.

Let me now explain the few things that, in my opinion, need some explanation.

Security and integrity

The kind of authentication used by the server is essentially the same as the standard authentication mechanism of UNIX, i.e., DES with salt. The integrity of a session is based on a random string of 8 characters from a 65 character set. Originally, that string was combined with the IP address of the client (making this approach practically 100% foolproof), but then I noticed that some applicants couldn't get back into their sessions after re-connecting to their providers with a different (dynamically assigned) IP address. I think it is still fine because an intruder (trying to get into a session in progress) would have to guess something of the complexity of a long (and completely random) UNIX password.

Note that all pages and forms generated by GAPS are represented by relative links. Consequently, if the banner page of a GAPS session is referenced as a secure page (its URL starts with https://), the entire session will be encrypted.

The database is backed up regularly every day.


To save on time and space, we do not differentiate between preliminary and proper applications. All the information the applicants supply with their pre-apps must find its way into the final application, so why bother separating the two. This is how it works.

When a new applicant comes in, he/she clicks the "new applicant" button on the entry form. Then they are asked to choose a username and password, and to select the academic year for which they want to be admitted. If the username is already in use (for the selected year), they are asked to select another name. For a complete pre-app, they have to fill some specific information. If they sign off without doing that, they are warned that the information they have entered will not be stored in the database and the username will be discarded. This way we protect ourselves against noise, i.e., forms submitted just for fun, attempted and abandoned applications, etc.

If an APPLICANT session has been abandoned (no activity for 90 minutes) it is automatically logged out. To be meaningful, i.e., to result in a database update, a session must be completed by a logout operation that "commits" the session.

A new (complete) pre-app file receives the status "Submitted". Anybody authorized to search the database (e.g., a committee or faculty member) can search files based on several criteria (including the application status). Thus we can easily identify new preliminary applications and process them at our convenience. One of the responsibilities of the graduate chair is to look at the preliminary applications, do the initial screening, request more information in dubious cases, and decide whether it makes sense to pursue the case. If so, the application status is changed to "Preliminary Application" and the applicant is notified that the preliminary application has been accepted.

In addition to the servers, the GAPS database is periodically scanned by a crawler process, whose primary role is to send automatic E-Mail to the applicants and perform some administrative (cleaning) tasks described by a set of modifiable rules. The crawler tries to make sure that every applicant's file is looked at at least every 4 hours. The applicant receives an automated E-Mail message in the following circumstances:

Regardless of the processing status of their applications, applicants can log on to the database at any moment and edit their files. They can also upload images and PDF documents, e.g., with their academic transcripts, CVs, theses abstracts, statements.

Starting from version 1.2 (release 34), reference letters for applicants can be submitted electronically. An applicant (as well as a committee member) can declare a reviewer by entering his/her name and E-Mail address on a form. GAPS generates a random (signed) URL and e-mails it to the reviewer. When the reviewer clicks the URL, he/she is presented a (secure) form that looks more or less like the standard (paper) reference form used in our department. The reviewer fills it out and submits. Then the form becomes available to the committee in the same way as a scanned letter.

Committee users

If you log on as a COMMITTEE-class user, you are presented with a form that lets you search through the files. One attribute of your session, that gets saved when you log off, is the list of files you are working on. You can easily add/delete files to/from the list. A separate list exists for every admission year, so you can work on multiple years (e.g., processing admissions for the current year and prelimnary applications for the next year) without messing up your desk.

By clicking on an applicant's file, you "link" your session to it (the terminology of the SICLE FORM server), which means that you effectively become the applicant user with possibly different (in this case higher) privileges. You can just browse through the file, but you can also modify it, in essentially the same way as the applicant. The layout of the forms is slightly changed, compared to what is seen by the applicant. Two more forms available to you and not available to the applicant are the reference letters and committee/faculty comments.

When you are done, you are supposed to close the file. Otherwise, it will be closed automatically after 30 minutes of inactivity. Having closed the file, you "unlink" from it, i.e., you get back to your master session (and are shown the search page again).

With multiple browser windows (or even with a single window), you may have several applicant files open (linked to) at a time. You should remember that for as long as a file is open, nobody else is allowed to look at it, including the applicant, other committee members, and the faculty. A user trying to access the file gets a message that the file is (temporarily) locked.

The search engine may be a bit slow (it has been implemented entirely in a scripting language), but it should be fine for a thousand or so records. It will be re-implemented if there are serious problems.

It is possible to send E-Mail to an applicant. This can be done from the "address" or "comments" form (by clicking the mail icon). Another possibility is to click "mail to selected" on the search page. You have to select at least one applicant (on your current list of files) to receive the E-Mail. This gets you to a special form which you can fill with a number of standard messages (they will be saved across your sessions). A similar form is displayed in response to "mail to faculty". Using it, graduate committee members can notify the faculty about interesting applicants.

Your outgoing E-Mail addressed to applicants can be signed with your PGP key. To be able to sign your E-Mail, you have to login as gradinfo (preferably on menaik) and add your key to the key ring. The user ID of the key must match the E-Mail address that you will be using as your return address for the outgoing E-Mail. Then, whenever you want to sign your message, just insert your PASS phrase into the respective field on the mail form. The phrase will be remembered for as long as your session is alive, but it won't be stored across your sessions for obvious security reasons. If you are not familiar with PGP, but still want to sign your messages, I will help you set it up properly.

One use of the GAPS E-Mail feature was to notify the applicants about the status of their applications, but this obvious purpose has been made obsolete by the crawler, which does it automatically these days. Also, if there's a problem with the application, it is generally sufficient to insert a message to the applicant into the respective text area on the "comments" form, and the crawler will automatically bring it to the applicant's attention.

The application status can be one of these: "Submitted", "Held" (usually meaning "waiting for some clarification from the applicant"), "Application Incomplete", "Pending", "For Review", "Admitted", "Accepted" (i.e., the applicant has accepted our offer), "Declined", "Rejected", "Cancelled", "Withdrawn" and "Archived" (meaning "postponed or ignored for now).

Faculty users

A FACULTY-class user sees (almost) exactly the same information as a COMMITTEE-class user, but most of this information cannot be changed. The server uses the same forms (or rather form templates) as for COMMITTEE users, with a dynamically changed layout. In particular, the search form looks exactly the same as in the FACULTY case.