[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Alarms - was RE: Question on calstore current time.



Just a thought along these lines:

First - how do vendors CURRENTLY handle alarms - i.e. can the vendors here
each speak up and explain how they handle it today... interoperability etc
will be greatly eased if we set a standard that is not too distant from
current practices.

Second - fundamentally what are the REQUIREMENTS around alarms? Are ALL
alarms a user-centric condition - i.e. each attendee for a given event might
want DIFFERENT alarm conditions (including no alarm at all) - if this is the
case - do they belong in CAP at all?

Shannon

-----Original Message-----
From: owner-ietf-calendar@xxxxxxxxxxxx
[mailto:owner-ietf-calendar@xxxxxxxxxxxx]On Behalf Of Doug Royer
Sent: Wednesday, December 19, 2001 3:12 PM
To: ietf-calendar@xxxxxxx
Subject: Re: Question on calstore current time.


John Stracke wrote:
>
> >What if I want it to go to the CUA that I am connected with?
> >And not a specific CUA? As in if ANY CUA is connected, then
> >the CUA will send the alarm, else the CS  sends it.
>
> I think there are problems with that.

Yep.

> The big one: Suppose the clocks on the CUA and the CS are not in
> sync--say, the CS's clock is 1 minute ahead of the CUA's.  I have an alarm
> set for 2:00.  At 1:59:30, CS time (1:58:30, CUA time), the CUA connects.
> At 2:00:00, CS time (1:59:00, CUA time), the CS decides it doesn't need to
> send an alarm.  At 2:00:10, CS time (1:59:10, CUA time), the CUA
> disconnects and exits.  At 2:00:00, CUA time, the CUA is not running, so
> it doesn't send an alarm.  The alarm is lost.

Yep. The same problem exists if several CUA's are connected and
you only want one to send the alarm.

> In addition, there are a couple of scenarios involving CUAs that don't fit
> the mold of a long-lived app with a continual connection to the CS.  For
> example, you might have a daemon syncing your calendar down to a desktop
> PIM; it's got no UI at all, and shouldn't be sending alarms.  Or you might
> have a Web-based app that makes transient connections to the CS; the only
> way for it to handle alarms would be if it queried the CS for them on
> every single page view.

We need MUCH more work on the alarms. I don't think this should
slow down or stop CAP. But it is unresolved.

-Doug