[Dev] Proposal for Alarms based on Reminders

[Jeffrey Harris]

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?

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.

(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