[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] libkcal amendments for email alarms
From:       David Jarvie <lists () astrojar ! org ! uk>
Date:       2002-11-30 0:18:44
[Download RAW message or body]

On Friday 29 Nov 2002 11:02 pm, Cornelius Schumacher wrote:
> On Friday 29 November 2002 23:36, David Jarvie wrote:
> > I want to store some statuses which I have previously encoded as a
> > prefix to the alarm text in the description property, in order to
> > make the description a plain text and to adhere better to the spirit
> > of RFC2445. There are likely to be 4 or so statuses including
> > repeat-at-login and cancel-if-late statuses which KAlarm needs to
> > record in order to know when or if to output certain alarms. I intend
> > storing all the statuses applicable to any particular alarm in a list
> > held in a single custom property.
>
> Are these really attributes of the alarm itself? Aren't these rather
> user preferences associated with certain alarms?
>
> Take for example an alarm for starting the daily backup. For a system
> administrator who is responsible for actually performing the backup a
> cancel-if-late status is certainly not appropriate. For a user which
> just wants to get notified, when the backup takes place, such a status
> would be very useful. If you store the status as part of the alarm, it
> isn't possible for both, the system administrator and the user to share
> the same iCalendar data.

As far as KAlarm is concerned, I have always intended it as a _personal_ alarm 
scheduler, and a system administrator therefore would not share alarms with a 
user. So I'm not sure what to make of your argument. However, some other 
statuses do, I think, definitely belong in the VALARM component. Here are the 
statuses which KAlarm needs, in decreasing order of user-independence:

File: This indicates that the DESCRIPTION property in a DISPLAY alarm contains 
the URL of a file whose contents are to be displayed. This is most definitely 
an intrinsic part ot the alarm which is not in any way user-dependent. This 
is to be distinguished from FILE alarms which are used to specify program 
files to be executed, not to be displayed. KAlarm will use FILE alarms for 
that purpose.

Repeat-at-login: this is in effect a different type of recurrence whose 
repetition times are defined as when the user logs in rather than at preset 
fixed times. The repetitions continue until the end time specified, at which 
point the alarm is activated one final time. This definition is also 
user-independent, although the actual trigger times are dependent on the 
user's habits.

Deferral: this indicates that the alarm was originally triggered by a 
recurrence, but has been deferred so that it will trigger again at a 
specified time later. (If the recurrence has not yet finished, the recurrence 
alarm will also still exist in the event, as a separate alarm.)

Cancel-if-late: this is a property which is set for the alarm when it is 
defined. If it was to be used by different users, they clearly could want it 
set differently.

Displaying: This indicates that the alarm is currently being displayed to the 
user. If the alarm has otherwise expired, it ensures that the alarm is 
redisplayed should KAlarm be killed or crash. This is user-specific.

I would strongly argue for the first 3 statuses at least to be stored in the 
VALARM. If KAlarm remains exclusively a _personal_ alarm scheduler, the 
others can also be there, but obviously if that changed, they would need to 
be kept elsewhere.

-- 
David Jarvie
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]