From kde-pim Sat Nov 30 00:18:44 2002 From: David Jarvie Date: Sat, 30 Nov 2002 00:18:44 +0000 To: kde-pim Subject: Re: [Kde-pim] libkcal amendments for email alarms X-MARC-Message: https://marc.info/?l=kde-pim&m=103861563721224 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/