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

From: [email-masked]
Date: Fri, 21 Dec 2001 11:56:02 -0500

John replied:
>Wait a minute; I think we've got another disconnect. 

Nah, we never have those here... :^)

>                                                      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.   If not engineered properly, 
its possible that ATTENDEEs get 2 email reminders where only 1 should have 
been sent.

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 (or can 
change outside of the control of the CUA such as in a "Westford Employees" 
mailing list maintained by someone else).  This is a bell and whistle type 
feature but one that could not be implemented if the CS did it 
automagically for the CUA.

Also, the CS can send the email alarm on behalf of the CU but not all C&S 
systems have that as their model currently.  As stated before, by myself 
and others, this is an area that has not had any real cycles spent on it 
to deal w/disparate models of behaviour between the different products 
that currently exist.  Chalk it up as an issue set that needs to be 
addressed.  However I think that there are bigger fish in the CAP pond 
that need frying before we deal w/something of this size.

>     if a CUA is running and intends to report the alarm, it doesn't need 

>the CS to tell it so.  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.  For example, my AA gets a call from another mgr requesting some 
block of time so she 'over books' me and sets a display alarm for me to 
see to get me out of my other meeting(s).  As such, if the CUA only polled 
hourly (or longer) it would miss new entries that arrive in that time 
frame. 

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 "what alarms are scheduled to trigger in the next xx minutes" also 
does not address the "What alarms did I miss since I last checked / logged 
in" case where a CUA or CS can be unavailable when query would have 
normally detected it or is one of the examples above.

>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. 

To keep the designe simpler, I think that the CS should not be involved in 
servicing any alarms since it removes the "Im a 'client pull' CS and he's 
a 'server push' CUA so what do we do?" quandry.  If the CUA was 
responsible for handling all alarms then its keeps this part of CAP simple 
to grok and more likely to allow for better interop.

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

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

[email-masked] wrote:

> Granted that the ATTENDEE list is fully expanded in the alarm when
> stored, ...

Why? Are you saying the CS expands the list?
If not the CS, then why would the CUA expand the list prior to storing?

> ... it is not inconceivable that a CUA would want to possibly
> refresh the list before sending the email if the group membership has
> changed (or can change outside of the control of the CUA such as in a
> "Westford Employees" mailing list maintained by someone else).  This
> is a bell and whistle type feature but one that could not be
> implemented if the CS did it automagically for the CUA.

Sure it could, store the VALARM with the 'Westford Employees" mailing
list, and when the alarm went off, let the mailer (MUA or MTA) expand
the list as they can do that anyway. The CU said "list name", not
only who is on the list now. No matter if the CUA or CS sends
the alarm.

> Also, the CS can send the email alarm on behalf of the CU but not all
> C&S systems have that as their model currently.  As stated before, by
> myself and others, this is an area that has not had any real cycles
> spent on it to deal w/disparate models of behaviour between the
> different products that currently exist.  Chalk it up as an issue set
> that needs to be addressed.  However I think that there are bigger
> fish in the CAP pond that need frying before we deal w/something of
> this size.

I agree. We can ship CAP and solve this later.

> That would work if I didnt allow other CUs to access and put entries
> on my calendar.  For example, my AA gets a call from another mgr
> requesting some block of time so she 'over books' me and sets a
> display alarm for me to see to get me out of my other meeting(s).  As
> such, if the CUA only polled hourly (or longer) it would miss new
> entries that arrive in that time frame.
> 
> 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).

Or the notification model that we opted out for this version
of CAP. Perhaps we can solve this issue at the next revision
when we solve the notification issue.

> ...>This scales better, because it doesn't require the CS to do as much
> work
> This argues for a 'client pull' model for alarms.  Since thats the
> model we've had for years Im kinda partial to it.

Then we could agree to defer this until we can figure out
how to have off-line alarms. I would agree as:

	Any CS that does it now has only a web or real stupid CUA.
	and those CUAs can not do it anyway so it would have to
	be a vendor specific feature for now.

	Any CS that does not already send alarms for the CUA is not
	going start soon. So it will work for those vendors already.

> To keep the designe simpler, I think that the CS should not be
> involved in servicing any alarms since it removes the "Im a 'client
> pull' CS and he's a 'server push' CUA so what do we do?" quandry.  If
> the CUA was responsible for handling all alarms then its keeps this
> part of CAP simple to grok and more likely to allow for better
> interop.

I Agree (until we have notification :-)