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

From: "John Stracke" <[email-masked]>
Date: Thu, 20 Dec 2001 13:12:28 -0500

>I suspect that in order to get a "client pull" CS to work with a
>"server push" CUA that some negotiation between the two is going to
>be necessary and the same for the converse rolls.

Definitely.  Unless we want to mandate one way or the other (a Bad Thing, I think), 
we'll probably need some way for the CUA to say, "please push this alarm", 
and for the CS to say yes or no.

/=======================================================\
|John Stracke                   |Principal Engineer     |
[email-masked]  |Incentive Systems, Inc.|
|http://www.incentivesystems.com|My opinions are my own.|
|=======================================================|
|Round up the usual disclaimers.                        |
\=======================================================/

---

From: "John Stracke" <[email-masked]>
Date: Thu, 20 Dec 2001 14:30:21 -0500

>I am struggling a bit to see a clear reason alarms are a standardized
>element - i.e. they seem to be very specific in nature to a given
>vendor's application - unless we are suggesting that there be two
>elements to an alarm - one "when it should happen" - and a second,
>specific to a given application, of "what" should then happen????

No.  There are very clear semantics on what happens for alarms.  See 
RFC-2445, section 4.6.6.

The only real variation going on here is the division of labor between CS 
and CUA.

/=================================================================\
|John Stracke                   |Principal Engineer               |
[email-masked]  |Incentive Systems, Inc.          |
|http://www.incentivesystems.com|My opinions are my own.          |
|=================================================================|
|"Fly Heisenberg Airlines! We may not know where we are, but we're|
|making real good time." -- _Synners_ by Pat Cadigan              |
\=================================================================/

---

From: [email-masked]
Date: Thu, 20 Dec 2001 17:03:32 -0500

"Shannon J. Clark" <[email-masked]> wrote on 12/20/2001 01:31:35 PM:
> Thanks - I guess what I am getting at when I ask whether CAP must 
> address alarms is asking whether alarms are fundamental (i.e. a 
> requirement) for interoperating calendar systems - or whether they 
> are a characteristic of Calendar USER agents

I seriouly think the answer is YES!  CAP is supposed to be the protocol 
that allows a user to use ANY CU to access their calendar on anyones CS.  
Part of doing this is being able to access the alarm(s) on an entry.   The 
real issue that has yet to be directly addressed is how to get a "push" 
both "pull" clients/servers to play nicely together.  Otherwise our users 
will just say "My alarms dont work when I try to get to my calendar on 
Blech's server.  It worked w/Sanzzy's server!  The other server must be 
broken".  Frustrating our users by removing functionality that they rely 
on is NOT a good idea.

Unlike a CUA that polls the CS for any new requests, etc,; alarms are more 
time sensitive in order to remain functional.  Perhaps its confusing you 
that CAP is not funamentally a push model but for alarms in some models it 
is...

> I am struggling a bit to see a clear reason alarms are a 
> standardized element 

You are mixing the standardizing the representation of an alarm in 
iCalendar and their actual usage 'implimentation' in a CUA using CAP. Dont 
confuse the two.  iCalendar absolutely is correct to represent alarms in 
the core standard.  Whats costing you gray cells is functional interop 
design for an area thats been neglected.

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: "John Stracke" <[email-masked]>
Date: Thu, 20 Dec 2001 17:45:54 -0500

>Unlike a CUA that polls the CS for any new requests, etc,; alarms are
>more time sensitive in order to remain functional.  Perhaps its
>confusing you that CAP is not funamentally a push model but for
>alarms in some models it is...

Wait a minute; I think we've got another disconnect.  I was thinking the 
only kinds of alarms the server might watch for would be the email-based 
ones; 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.  (Or 
more, actually--say, 90 minutes--to avoid edge problems.) Then it sets an 
internal reminder to report those alarms when they occur.

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.

/=========================================================\
|John Stracke                   |Principal Engineer       |
[email-masked]  |Incentive Systems, Inc.  |
|http://www.incentivesystems.com|My opinions are my own.  |
|=========================================================|
|Peace, justice, morality, culture, family, sport, and the|
|extinction of all other life forms!                      |
\=========================================================/