[Dev] Proposal for Alarms based on Reminders

[Donn Denman]

Jeffrey,

On Nov 30, 2004, at 2:11 PM, Jeffrey Harris wrote:

> Hi Donn,
>
>>> 2. the alarm can repeat a finite number of times (for each event or 
>>> todo in a possibly infinite VTODO or VEVENT reccurence set)
>> We're not planning to repeat Reminders, but that can be added later 
>> easily.
>
> Sure.
>
>>> 3. the alarm ACTION can be display, email, audio, or execute a 
>>> process
>> Our Reminders will trigger a CPIA event, which gives us a lot of 
>> flexability.  For instance, the event could be broadcast, so it could 
>> be picked up by a 3rd party parcel that could send an Email, etc.
>
> Under the covers, triggering a CPIA event certainly makes sense.  I'm 
> sure import/export can be made to work with that, but to do so may 
> require a fair amount of work.
>
> Say, for instance, that I'm importing an event with an alarm that says 
> to email a certain message and subject to 3 addresses 6 hours before 
> the event takes place.  Is it easy to stick all this information into 
> a CPIA event to be processed later (I don't know the answer to this, 
> if it's easy, I guess we're done)?  And if the resulting CPIA alarm is 
> associated with the event, how do I know the exported VALARM should 
> have ACTION=EMAIL?
It is easy to add arbitrary information to a CPIA event, though that 
information is not persisted.  I think this is fine in our case, since 
the event is created at runtime by the Reminder (and the associated 
Timer) when it triggers the event, so it can add this Reminder-specific 
information to the event before it's sent out.

> To be honest, I don't know how many applications other than Evolution 
> actually offer email alarms, I don't think Outlook does yet.
>
>>> Re: 3., I don't know if we've got any plans to allow alarms to 
>>> trigger the sending of emails, but that sure would be useful for me. 
>>>  So, I think we should have an action attribute for however an alarm 
>>> is represented in the Content Model, even if we don't implement any 
>>> other actions than display for now.
>> Do you think a CPIA event fills the "action" bill well enough?  
>> Admittedly, I'm looking more at the internal representation, and I 
>> think you are looking more at the user perspective.  Maybe something 
>> like triggering a user script is more along the lines you're 
>> thinking?
>
> The nice thing about sticking this kind of detail in the Content 
> Model, from my perspective, is that the API is pretty obvious, if I 
> can just stick an alarm with all the relevant info in the repository, 
> I don't have to worry how the notification framework will process that 
> data. But I'm not even vaguely attached, as long as there's a 
> reasonably obvious and stable algorithm for constructing the right 
> CPIA event and interpreting a stored CPIA event, I'm happy.
>
> To put this in perspective, I really don't think it's the end of the 
> world if alarms don't have a lot of fidelity on import, export 
> fidelity is impossible and even less important it seems to me.  The 
> most commonly used piece, beep at me 20 minutes in advance of my 
> appointment, should work smoothly because people actually use that on 
> their PDAs, if we just assume all alarms exported or imported beep, 
> that's probably fine.  You probably don't want your PDA to try to 
> email you even if that's what you wanted your desktop application to 
> do.
>
So the big question is whether we should try to represent all of the 
VALARM functionality in the Content Model even if the UI only pays 
attention to a small subset of it.  This could be important if there 
are applications that want to look at the calendar information when 
it's on the WebDAV server.  There may be other issues, such as getting 
the Content Model right the first time in order to minimize changes as 
the UI evolves.  On the other hand, we don't want to clutter up the 
Content Model with a lot of stuff that's unimplemented, and may not be 
any time soon.  This is probably one instance of a bigger policy 
question that probably should be raised.

> (slight tangent) Even though it's part of the RFC, I think executing 
> user scripts or external processes based on an icalendar file which 
> may be received in an email is a security risk, so I think we should 
> either not offer this or think carefully about how to do it securely.
>
>> Bryan has been working on an architecture that should solve this 
>> problem - the various Reminders are collected into an Item 
>> Collection/Query, and sorted so the one set to go of soonest is the 
>> only one with an actual Timer connected to it.  This should also 
>> solve the problem of expired Reminders - if you don't run Chandler 
>> for a long period the next time you start up the Query associated 
>> with the Item Collection makes it easy to gather all the "missed" 
>> Reminders so the UI can give one coherent message about them.
>
> Marvelous!
>
> Sincerely,
> Jeffrey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4928 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20041201/85b29785/attachment.bin