Subject: Re: Question on calstore current time.

From: "John Stracke" <[email-masked]>
Date: Wed, 12 Dec 2001 18:54:42 -0500

>Perhaps we need a way to say what the CUA expects?

>         (a) CS Always processes VALARMs.

This won't work, because some VALARMs aren't possible on the server side 
(e.g., audio alarms)

>         (b) CS Only processes VALARMs when the CUA is not connected.

"When the CUA is/is not connected" is tricky, because you can get a race 
condition: the CUA crashes, the CS decides not to process a VALARM because 
the CUA is connected, then the CS notices the CUA has disconnected.  The 
alarm never goes off.

Also, more prosaically, the bit that processes alarms may be a completely 
separate process from the bit that speaks CAP.

>         (c) CS Never processes VALARMs.

This is valid, and simple.  A helper daemon polling the CS via CAP would 
suffice to make email-based alarms work.  Of course, the helper daemon 
would need privileges to read all VALARMs.

>         (d) CS Only process the tagged VALARMs.

This might be a good approach; then the CUA can say, "please handle this 
VALARM when it goes off", and the CS can say, "I can't handle audio 
alarms, you dope.".

>         (e) CS Only process the tagged VALARMs when the CUA is not
>             connected.

See (b).

>         (f) CS Only processes specific types of VALARMs (email only
>             for example).

This might work.  We'd have to either (1) standardize on a set of required 
types (and only email can be reasonably required) or (2) expose the list 
of supported types in the capabilities.

>         (g) CS Only processes specific types of VALARMs when the
>             CUA is not connected.

See (b).

So, the choices are: (c): none; (d) CUA asks for alarms on an individual 
basis; (f1) CS processes all email alarms; (f2) CS processes an advertised 
set of alarm types.

Personally, I'd prefer (f1) over (f2) (of the standard types, only email 
makes sense anyway), and (d) over (f1) (the CUA might prefer to sign the 
alarm message, for example).  But (c) would not trouble me.

/=======================================================\
|John Stracke                   |Principal Engineer     |
[email-masked]  |Incentive Systems, Inc.|
|http://www.incentivesystems.com|My opinions are my own.|
|=======================================================|
|All your problems can be solved by not caring!         |
\=======================================================/

---

From: Doug Royer <[email-masked]>
Date: Thu, 13 Dec 2001 18:33:33 -0700

> would need privileges to read all VALARMs.

Would ALL CUA's send alarms - including the one the user
is connected to? If not, how would they know other CUA's were
connected?

> >  ...      (d) CS Only process the tagged VALARMs.
> 

We would need a new property / parameter in VALARM for this to work.

My real purpose was to point out that I don't think that this
has been discussed yet on this list. I would lean for (d), with
a capability or VCAR in the CS to signify what kinds of alarms the CS
can support at all or will do for the authenticated entity.
Should we tweak VCAR to add this? What the CS will do
may depend on the calendar, source of VALARM, or authenticated
or anonymous requesting entity.