Perry The Cynic wrote:Dewster35 wrote:Perhaps I'm thinking too narrow mindedly, but wouldn't you want the event end and event deleted to have the same function? I get that ical probably calls out these two things differently, but I would think... assume :/ that most people have an event start something and an event switch something back? And they would want the trigger to change it back to be the same whether it ended naturally or if it ended by someone deleting it? Same thing goes for the start of an event or a new event that is occurring now.
Roughly, Calendar Event events report time passing, while Calendar Change events report editing of the calendar itself. They are very different things. Consider the case of a repeating event. Ending it means the current instance has ended. Deleting it means they're all disappearing and the event will never happen again.
I agree that deletion of an active event should signal termination as if a currently active event had ended. I can do that fairly straight-forwardly. But that's not the whole answer. What should happen if the calendar event gets edited and moved away from now? What should happen if a new calendar event is created straddling the current time? For that matter, what should happen for multiple overlapping calendar events that happen to both match your criterion? Some responsibility, in general, will have to lie with the user... which is why they are two different events, one specifically reporting editing activity.
Cheers
-- perry
All good points... understood. I figured I was just looking at it too narrow mindedly.
I guess I was speaking more to the deletion of the event signaling the same as an event had ended naturally. I would also say that if a new event is created straddling the current time that it should treat the moment the new event is created as a start time... but perhaps that is just me in my use.
I agree that there does need to be multiple types... I guess I just think some bits in the second type are the same as the first and should perhaps trigger as such? Giving the flexibility to the user to do anything they would like also keyholes me to cover myself with double the amount of triggers in case those two events above occur. That that I'm averse to triggers, a quick look shows I've got 559 of them, but I do try to be efficient whenever possible.