🚀 go-pugleaf

  I seem to have discovered this discussion rather late, but... I happen
to be finishing up an implementation of a calendar program that allows
people to make meetings with each other through it.
  The first feature I implemented to this end (after getting the
functionality of a standard calendar program in) was the ability for the
user to select a set of
other users and see on a chart the times they were busy overlayed. That
is,
across the top of a grid are the days of the week, and down the left
side are
hours from 9 to 6, in increments of 30 minutes. Each cell is shaded
according
to how many people are busy, according to their calendar, during that
half hour. (The user may trivially block off any times s/he chooses as
being busy.)
  People found this feature alone massively useful in facilitating
making appointments with small groups of people (which in general seems
to be the need here).

  On to the code I'm finishing up now:
  The user selects a group of people s/he wishes to have a meeting with,
and potentially pages ahead a week or so to find a time that seems to be
adequate for everyone, or most everyone. There is nothing preventing the
user from selecting a time that someone has marked busy. S/he selects
the time and enters a description of the meeting, and then instructs the
program to send the meeting information to the "meeting server." The
meeting server is more or less a mail server in functionality, but more
suited in various ways to this task. The meeting server sends
notification to those recipients who happen to be logged in that there
is something waiting for them on the meeting server.
  With the calendar program, the recipients will eventually
"incorporate" their
new meetings. These new meetings will come up in a distinct window at
this point. Meetings may be tagged as "tentative," "final," or
"cancelled," though in the case
of just having received a new meeting it is much more likely to be
"tentative."
  At this point the recipient has the option of responding to the
(proposed) meeting time one of "yes," "no," or "maybe," along with a bit
of text for a counter-proposal time or whatever s/he may wish to say
about it. In addition to this, the recipient chooses whether to add this
appointment to the calendar or not, and whether or not it should show up
as time that s/he is "busy."
  These responses are returned through the server to the initiator of
the proposed meeting, who may decide either to finalize that meeting
time, or to cancel that meeting proposal and initiate a new one for a
different time. Finalizations and cancellations of meetings will again
go through the server to the recipients.

  So does anyone see any major problems with this? It's not running yet
(it hopefully will be by next week), but I don't see any problems with
it for this environment (provided of course, that people involved
actually _use_ this program and keep it up to date). Are there
environments where you would expect it to fail?

  There are a few choices to make in implementing this model, but that's
essentially it. The client is an X based Motif program, and has a
few dependencies on the environment of Project Athena. Client and server
authenticate through Kerberos, and the server notifies users of new
messages through Zephyr. Programs already exist that do appointment
making in various ways, but none that I know of are really usable in the
Athena environment.

Craig Fields       cfields@athena.mit.edu
MIT-Project Athena