phcalama@dial.waterloo.edu (Paul Calamai) (04/12/91)
I'm experiencing the following weirdness with the calendar
tool under OpenWindows2 on a Sparcstation2 running OS4.1.1:
(1) If I create an appointment that starts 1hr 15min from
the current time with the mail notification set to 1 hour
in advance, and I stay on the node, I get the mail ~ 1 hour
in advance.
(2) Under the same scenario if I log off the node and return to
it some time after the apointment I don't have any mail
in my InBox relating to the (missed) appointment.
Any ideas about what gives?
--
Professor Paul H. Calamai email: phcalama@dial.uwaterloo.edu
Dept. of Systems Design Engineering phone: (519)885-1211 ext. 3182
University of Waterloo fax : (519)746-4791
Waterloo, Ont. CANADA N2L 3G1 telex: 069-55259weimer@garden.ssd.kodak.com (Gary Weimer (253-7796)) (04/12/91)
In article <1991Apr12.130031.4684@watdragon.waterloo.edu>, phcalama@dial.waterloo.edu (Paul Calamai) writes: |> I'm experiencing the following weirdness with the calendar |> tool under OpenWindows2 on a Sparcstation2 running OS4.1.1: |> (1) If I create an appointment that starts 1hr 15min from |> the current time with the mail notification set to 1 hour |> in advance, and I stay on the node, I get the mail ~ 1 hour |> in advance. |> (2) Under the same scenario if I log off the node and return to |> it some time after the apointment I don't have any mail |> in my InBox relating to the (missed) appointment. |> |> Any ideas about what gives? I would assume that cm does the time check for mailing the same time it does the check for bells and popups. i.e. has the algorithm: if (time to send mail) mail <params> instead of doing something like: insert appointment into calendar if (send mail) X = appointment time - notify time # notify time = 1hr in your case at X mail <params> # we can now ignore mail notification NOTE: at command could not really be used like this, but you get the idea Since cm does not tell the system to send the mail at some future time, cm must be running when the time to send mail actually occurs; otherwise, it doesn't get set. weimer@ssd.kodak.com ( Gary Weimer )
nannette@Eng.Sun.COM (Nannette Simpson) (04/15/91)
The daemon, rpc.cmsd, stores only tokens to represent reminders. It has no semantic knowledge of these tokens, nor does it execute any action based on them. It's up to the client (i.e. CM) to ask for the next reminder token, interpret it in a manner appropriate to its environment (i.e. CM is a window-based tool so putting up a popup window is an appropriate interpretation of a token) and execute it. The problem is ... there is a certain class of reminders which users expect to execute in the absence of any clients (i.e. mail). I refer to these as "persistent reminders." Currently, the tools make no distinction between client-specific and persistent reminders. That's why you must have a client (CM) present for mail reminders to go off. The design for reminders is being reworked. ______________________________________________________________________ Nannette Simpson Internet: nannette@Eng.Sun.COM Sun Microsystems, Inc. UUCP: ...!sun!nannette 2550 Garcia Ave. MS 1-40 Phone: (415) 336-2969 Mountain View, CA 94043 Intelligence without character is a dangerous thing. --G. Steinem