Subject: RE: Alarms - was RE: Question on calstore current time.

From: "John Stracke" <[email-masked]>
Date: Fri, 21 Dec 2001 14:06:13 -0500

>>                                                      I was thinking the 

>>only kinds of alarms the server might watch for would be the email-based 

>>ones; 
>
>Again, depending on the current CS and CUA models this is not 
automatically a good thing to have happen.

Well, that's why I don't want it to happen automatically; I don't want the 
CS to take on any alarm without being asked, and I want the CS to be able 
to refuse.

>Granted that the ATTENDEE list is fully expanded in the alarm when
>stored, it is not inconceivable that a CUA would want to possibly
>refresh the list before sending the email if the group membership has
>changed

Probably not a good idea; you'd wind up sending a reminder to someone who 
never got the invitation.

>>It can just query the server, say, once an hour, 
>>and ask for all the alarms which it should report in the next hour. 
>
>That would work if I didnt allow other CUs to access and put entries on 
my calendar.

Bleep.  Right.

(Personally, I've always felt that a good scheduling system should obviate 
the need for an assistant to put things on your calendar; but I'm aware 
that PHBs are not going to give up that status symbol easily.)

>Add to this mix the ability to have the CS autoprocess requests (ie:
>from my mgr gets overridding priority compared to my peers) then its
>apparent that smaller polling windows are necessary (in the client
>poll model).
[...]
>>This scales better, because it doesn't require the CS to do as much
>>work 
>>to service all the alarms; it pushes the work to the edges.
>
>This argues for a 'client pull' model for alarms.  Since thats the
>model we've had for years Im kinda partial to it.

Yeah, but your model is based on the CUA having a complete copy of what's 
in the CS (as near as I can tell from having used it the past two months). 
 A thin-client model might not be able to cope with that.

And the alternative is polling, which is really hard on the CS--harder 
than having the CS poll itself at similar frequency.

So maybe we need a way for the CS to push alarm reminders to the CUA? Only 
if it's been asked to, of course.

/=================================================================\
|John Stracke                   |Principal Engineer               |
[email-masked]  |Incentive Systems, Inc.          |
|http://www.incentivesystems.com|My opinions are my own.          |
|=================================================================|
|Whose cruel idea was it for the word "lisp" to have an "S" in it?|
\=================================================================/

---

From: Doug Royer <[email-masked]>
Date: Sun, 23 Dec 2001 18:45:37 -0700

> that PHBs are not going to give up that status symbol easily.)

Not always a status symbol. It could be a company or group
calendar where the maintainers of the calendar are multiple people.

>  A thin-client model might not be able to cope with that.

The CUA only needs to know the times of the alarms, then when the
alarm is about to go off, VQUERY for whatever else it needs.
There is (was?) and example of this in CAP. Each poll need only
poll for alarm times and current "display" view range. It MAY
pull down more.

> than having the CS poll itself at similar frequency.

I also don't like the poll model. But for now it works.
 
> if it's been asked to, of course.

A.K.A. - notifications.