[123] in DCNS Development
design review for a Macintosh OLC/OLCR client
daemon@ATHENA.MIT.EDU (kkkken@Athena.MIT.EDU)
Thu Sep 26 18:38:19 1991
From: kkkken@Athena.MIT.EDU
Date: Thu, 26 Sep 91 18:37:01 -0400
To: developers@Athena.MIT.EDU, dcns@Athena.MIT.EDU, css@Athena.MIT.EDU,
----------------------------------------------------------------------
DESIGN REVIEW FOR A MACINTOSH OLC/OLCR CLIENT
----------------------------------------------------------------------
-------------
Design Review
-------------
You are invited to a design review to discuss plans for a Macintosh
OLC/OLCR client. It will be held Thursday, October 3, 1991, from 3:00
to 5:00 pm in E40-316.
------------
Where We Are
------------
At this point, I have a working user interface (front end only) for a
user OLC client. It does no server communication and provides no
consultant-related commands. It only allows the user to ask
(multiple) questions, show replays, show simulated consultant
responses, and send messages. In addition, I have ported the UNIX OLC
client library (which contains code to form, send, receive, and parse
OLC packets) to the Macintosh, but it does not yet run, due to
failures in the transport-layer networking code.
---------------------------
Handling Multiple Instances
---------------------------
Right now, each instance is represented by a separate window. The
Macintosh "window manager" is the only way for the user (or
consultant) to switch between instances (the frontmost window is the
implied current instance). For a user, this may be acceptable. For
the aggressive consultant, however, I think it would result in an
unmanagable clutter of windows. I should implement a quick way of
getting between instances.
----------------------------------
Needed User Interface Improvements
----------------------------------
The user interface as implemented provides no facility for showing the
MOTD or showing consultants' hours; these should be added. There is
also a dubious distinction between telling the consultant that the
user is done with a question, and actually nuking the window
containing the most recent replay; how to handle ending questions has
to be resolved. As mentioned above, enhancements in handling multiple
instances would be desirable.
--------
OLC/OLCR
--------
Parallel to the UNIX version, I plan to develop one application to be
used by both consultants and regular users. When launched, it would
start out in `user' mode; a magic key combination would bring it into
`consultant' mode. The major difference would be the introduction of
new menus. First, a menu of general consultant commands would contain
the "dbload" and "dbinfo" items, and a "list" item to bring up a queue
listing. From the queue listing, the consultant could click on a
question to bring its replay up in a window. If no one was connected
to the user, that window would contain a button that the consultant
could press to grab the question.
A new menu of commands to manipulate instances would appear for
consultants, containing the commands "comment", "describe", "forward",
"mail", and "topic change".
-----------------------------
Server to Client Notification
-----------------------------
Probably the right way for the macintosh client to find out about
what's happening with the question would be to subscribe to
zephyrgrams and parse ones from the zephyr server. This is difficult
without a zephyr library. The way I think I want to do it now is to
use a forthcoming new server request, which makes the server use
`write' instead of zephyr. Then the OLC client can listen to the
write port, and parse incoming messages from the OLC host. This would
be bad if we eventually wrote our own write client, but this seems
unlikely. When something interesting happens to the question, we can
let the user know through the apple notification manager. Of course,
on existing platforms, the OLC client makes no attempt to keep track
of the state of the question or to notify the user of "interesting"
events.
----------------------------------------
Server Requirements of Macintosh Clients
----------------------------------------
Obviously, supporting another platform will result in an increased
number of clients and hence a larger server load. However, I think
that each individual Macintosh client will actually place _less_ of a
load on the server than its UNIX(tm)-based cousin, because the
Macintosh version caches replays and instance information.
--------------------
Unsupported Features
--------------------
Without NFS, I see no easy way to implement stock answers. I suggest
that they be added to techinfo, and accessed with the Macintosh
techinfo client, or be made available through a separate Macintosh
on-line help client.
The ability for a consultant to enter a question on behalf of a user
(for example, if the user made a phone call) would be useful. If the
necessary server extension is made, I will implement the OLCR client
side, as a consultant-only option to the "New Question" command.
Having multiple pools of consultants is, in my view, purely a server
issue. If the server will support a separate consultant list on (say)
a per-topic basis, I will have no trouble providing the OLCR client
support --- in fact, my guess is that no client changes would be
required. In a multiple-consultant-pool scenario, the "list" request,
for example, would presumably only give the client a list of those
questions that the consultant was allowed to grab; thus, the change
would be transparent to the client: it wouldn't know what it was
missing!
