The server is actually a workstation dedicated to running three separate OLC daemons which form the heart of OLC. These are:
- lock daemon
- This is the central program in charge of most OLC queries and transactions. Most clients interact directly with the lock daemon; it is the only daemon which performs actual OLC database changes.
- query daemon
- This daemon serves as an alternate to the lock daemon for retrieval of user logs and the OLC queue. Because it is dedicated to these two types of queries only, it is typically faster than the lock daemon. It is used by the
oreplayandolistclients described below.- poll daemon
- OLC keeps track of which users in OLC are currently logged in; the poll daemon periodically checks the login status of all OLC users, and notifies the lock daemon of the results. No clients communicate with the poll daemon.
Though technically the server and its corresponding daemons are distinct, the lock daemon---being the central manager of the OLC database---is usually referred to simply as the OLC daemon. In this context, the terms OLC server and OLC daemon are interchangeable, both referring to what is technically the lock daemon, with the query and poll daemons explicitly referred to as such when mentioned.
OLC clients interact with one another entirely via the server. Queries about OLC state, requests for state changes, and all other transactions are given to the server. Strictly speaking, clients never attempt to communicate with one another; rather, the user running a given OLC client communicates with another user on OLC, who typically is running another OLC client. This is important because, when for example a consultant is attempting to communicate with a user, the user may not be running a client. In this case, the server tries to contact the user via other means.
There are currently four different types of OLC clients, described briefly as follows:
- OLC
- Users use an OLC client to enter questions, and to interact with a consultant once they have been connected. Currently there are two OLC clients: the more widely used, but more primitive (from a user-interface point of view), text-based
olcprogram, and the X Window System/Motif-basedxolc.[1]- OLCR
- Athena consultants use the OLCR (for On-Line Consulting Reply) client to scan the queue for questions they can answer, to engage users in an interactive session, and to otherwise perform all their consulting duties. There are two OLCR clients:
olcr, the text-based counterpart toolc, and EOLCR, the Emacs-based OLCR client.oreplay- Not a class of clients but a specific client itself,
oreplayretrieves the log of all transactions with a specified user in OLC. Because it uses the OLC query daemon for its request, it is a fast alternative to callingolcr replay, which for the text OLCR client retrieves a user's log.olist- Like
oreplay,olistis a specific client. It retrieves the current OLC queue of users, in either the human-readable form given by an OLCR client, or in a ``raw'' format which is not quite readable by humans but which is broken down into well-defined fields which can be easily parsed by another program. Likeoreplay, it contacts the OLC query daemon, and is thus a fast alternative for retrieving the OLC queue.
The OLC and OLCR clients are the most widely and directly used, since
users use one and consultants the other. The olist and oreplay
clients were actually written for use by EOLCR (the Emacs OLCR
client), though they can be used independently.
Zephyr messages (also termed Zephyrgrams) are categorized by a
three field subscription triplet which determines the type of message
being sent, and to whom the message should be delivered. The first two
fields---the class and instance---determine the type of
message. The third field, the recipient, determines who will
actually receive the message. General-purpose messages contain a class
field of ``message''. If the message is addressed to a particular user,
the instance field is ``personal'' and the recipient field contains the
username of the user. (Note that a user must be subscribed to a
particular Zephyr triplet to receive the message. Subscriptions are
typically made with the zctl command.) Broadcast messages may
be sent to multiple users by specifying a recipient field of ``*'',
which is a wildcard specification. Any users subscribed to a triplet
with recipient ``*'' will receive the message.
To receive Zephyr notices, one invokes the zwgc (Zephyr
WindowGram client) command. Users running a zwgc program have
their location (i.e. what workstation they are logged in on) recorded
by the Zephyr servers. This location can be obtained by other users via
the zlocate command. Thus, Zephyr also serves as a location
tool: since most users run zwgc on login, zlocate is a
fairly reliable method of determining if a user is logged in.
OLC makes intensive use of Zephyr. Users with a question in OLC receive a Zephyr notice when they login telling them that their question is still active. When actually connected to a consultant, they are notified of new messages from the consultant via Zephyr, and receive other types of updates from OLC---for example their being connected to or disconnected from a consultant---via Zephyr. Finally, the OLC poll daemon uses Zephyr to determine if users are logged in.
Consultants rely even more on Zephyr. The OLC daemon broadcasts many changes in OLC state via Zephyr (using class ``OLC''), and consultants listen to these messages to stay up to date. New questions, questions being forwarded, logged out users logging back in, new messages from connected users, and others all generate a broadcast Zephyrgram describing the event.
Users and consultants are not the only ones to benefit from the OLC daemon's broadcasts; OLC clients can take advantage of them also. In particular, the Emacs OLCR client uses OLC Zephyrgrams to keep itself---and thus the consultant running EOLCR---updated. The details of how this works will be discussed later, but for now let it suffice to say that OLC's use of Zephyr performs some tasks vital to the efficiency of OLC as a whole.
All OLC questions, once answered, are archived into a Discuss meeting.[2] Questions are classified by topic; the name of the corresponding meeting is ``o'' (for OLC) followed by the topic. Thus, ``emacs'' questions are stored in the ``oemacs'' meeting, and ``unix'' questions are stored in the ``ounix'' meeting.
The archival of questions is an important aspect of OLC. It allows statistical analysis of OLC response time, load, and others, without disturbing the OLC protocol or software.[3] Furthermore, it allows experienced consultants to survey answers given to users to ensure that correct and accurate responses are being given; this will be discussed in the following section.
olc program by typing olc at the command shell (see Figure 2-2). olc, rather than prompting
the user for a question right away, presents the user with the option of
perusing a set of answers to commonly asked questions, and of seeing the
hours staffed by consultants in the OLC office. Also, olc displays the
OLC message of the day (MOTD), if there is one. The OLC MOTD is
a notice displayed by olc on startup which is installed by consultants to
inform users of current Athena problems which may be the cause of their
question.
ask. The user is first
prompted for a topic for the question; all OLC questions have a topic
associated with them. Table 2-3 lists all
valid OLC topics. Questions not covered by one of these topics---for
example questions about a special program used for a class, and that class
only---are not officially supported by Athena, and Athena consultants are
not required to answer such questions.[4]
| ||||||||||||||||||||||||||||
olc prompts for the text of the actual
question. The user now waits to be connected to a consultant who will
attempt to answer the question. If the user logs out before this
happens, mail will be sent to the user mail regarding the question. If
a consultant establishes a connection while the user is logged in, the
user can use the olc show and send commands to see
messages from the consultant, and to send the consultant replies. If
the user's question has been satisfactorially answered, the user informs
the consultant by using the done command; the consultant then
actually marks the question as resolved in OLC, thus removing it from
the OLC queue. This is called resolving the question. If a
user for some reason wishes to withdraw the question from OLC entirely,
the user may cancel a question by entering cancel; this
notifies the consultant that the question may be removed from OLC
without further consideration.
Not all questions are answered within a single session. Frequently the user logs out, either before or after a consultant connects to the question, or the consultant is unable to finish answering the question. In the latter case the question is forwarded, meaning that the consultant makes the question available for consideration by other consultants.
olc as shown
above, phone questions, or walk-in questions. Anywhere from one to
three consultants may be on-duty at a given time, although the average
is two during the day.
Consultants, when off-duty, can optionally also perform queue management, which consists of scanning the OLC queue and making sure of the following:
Consultants can also perform quality assurance by scanning the Discuss logs of previous questions, making sure that questions have been handled and answered correctly. If a consultant has, in a previous question, handled a question improperly or given inaccurate information, the quality assurance consultant sends a correction via email to both the consultant at fault and the user involved. The correction is also archived in the corresponding Discuss meeting for the benefit of other consultants scanning the logs.
Two chief sources of on-line documentation are available: Athena's On-Line Help system (referred to as OLH), and the OLC Answers to Common Questions (commonly referred to as the ``stock answers''); see Figures 2-4 and 2-5. OLH is a menu-driven application containing documentation about almost anything about Athena: Athena software, managing user's accounts, sending email, Athena policy, and possible interruptions in service due to maintenance.
|
|
Similar to OLH and the stock answers, the Consulting Reference (CRef) module accesses an on-line database of information specific to OLC. See Figure 2-5. It contains administrative information, people to contact for special questions or problems, transcripts of OLC training sessions, and an advanced version of the stock answers geared towards consultants. Users are never referred to the CRef database; it is meant for use by consultants only.
|
Finally, Dig allows consultants to search the Discuss transactions of previously answered questions. Dig takes a regular expression and a set of Discuss meetings, and finds all transactions whose titles---or optionally whose text---match the regular expression. Consultants use Dig to scan previous questions for possible answers to current questions.
|
- Active
- This queue is for users connected to a consultant. In this queue, the queue listing's ``Consultant'' column contains the consultant connected to the user.
- Pending
- This queue is for questions which have been connected to at least one consultant, yet remain unanswered. (I.e. the question is still ``pending'' an answer.)
- Unseen
- This queue contains new questions which have not been connected to any consultant. Note that this doesn't mean that no consultants have looked at the question, it only means that no one has actually been connected to it yet.
- Pickup
- Questions which require more information from the user are placed in this queue, where they remain until the user ``picks it up'' again by replying with the necessary information.
- Refer
- Questions requiring specialized knowledge of certain topics can be referred to a consultant---frequently a volunteer---known to be an expert in those topics. In such cases, this special-skills consultant is asked to review the question, and the question is placed in this queue until the consultant is able to review it.
- On-Duty
- OLC implements the concept of an on-duty consultant, who is always connected to at least one question. Under the on-duty policy, the consultant at work in the OLC office signs on-duty, using an OLCR client, and is immediately connected to a question. The on-duty queue lists all on-duty consultants. However, because the on-duty policy for paid consultants is not currently enforced at MIT---though OLC sites elsewhere may make use of it---it will be rarely discussed in this document.
The format of each question in the queue can vary from OLCR client to OLCR client, and in the Emacs client is customizable, but all share the following fields:
- Username
- The username of the user.
- Machine
- The name of the workstation on which the user is logged in.
- User Instance
- Each user has a specific user instance assigned, and OLCR clients always specify a username/user instance pair when referring to a user. The idea is that users asking more than one question in OLC would have a different instance number for each question, starting with zero for the first question. However, OLC currently supports only one question per user, so this column is almost always zero.[7]
- Login Status
- This column displays a `+' character if the user is logged in.
- Question Status
- This column displays a `D' if the user has entered
donein OLC, or `C' ifcancelwas entered.- Consultant
- If the user is connected to a consultant, this column shows the username of the consultant. Next to the consultant's username is the instance of the consultant with that user; each consultant is assigned an instance number for each question to which they are connected.
- Topic
- This is the topic of the question.
- Description
- This is a short description of the question, of up to 63 characters in length. The queue listing usually displays only a portion of the description, and all OLCR clients allow the consultant to specify whether the description should be displayed in the first place. The initial description of a new question is taken from the first 63 characters of the question.
- Date/Time
- The date and time (in 24-hour format) the question was asked.
- Number Connected
- The number of different consultants which have been connected to the question.
The queue listing provides a convenient summary of the questions in OLC. To see the complete question, a consultant replays the question. The resulting replay log contains the entire transaction log of the question; it includes the question itself, all messages sent between the user and the consultant, and other types of transactions (described below). See Figure 2-8.
|
In addition to sending messages or mail to a user, a consultant can insert a comment in the replay log; this is just that, a comment regarding the question. The user is not notified when a comment is inserted in the log, although the user will see the comment when replaying the log. Consultants not connected to the question can, and frequently do, insert comments into logs for the benefit of others. If a consultant wishes to insert a comment which for some reason or another should not be seen by the user---for example a comment containing private or OLC-only information---then a private comment can be used, which is just like a regular comment, except that the user does not see it when replaying the log.
A consultant unable to answer a question forwards the question to another queue: the refer queue if the question is being referred, the pickup queue if the user has logged out and more information is needed, and the pending queue otherwise. The description of the question is usually changed at this point to reflect the current status of the question; the topic may also be changed to something more appropriate. (Users frequently do not ask questions under the correct topic.)
Note that any consultant---not just the one connected to a question---can change topics or descriptions. This is useful for the consultant performing queue management, since it would be inconvenient to have to grab a question just to change the topic or description. Also, consultants can forward other consultants from their questions; this occasionally becomes necessary when a consultant is unable to disconnect from a question due to network failure.[8]