437196 - Fix calAlarm w.r.t X-MOZ-LASTACK

Status: NEW

(Calendar :: Alarms, defect)

Description

[Daniel Boelzle [:dbo]]

X-MOZ-LASTACK must not be stored inside the VALARM component.

Comment 1

[Bas van den Bosch]

Why not? in the future we might have multiple alarms (bug 353492)

Comment 2

[Daniel Boelzle [:dbo]]

We refrain from creating exceptions/overridden items when dismissing an alarm on a single occurrence to not bloat the calendar with redundant data. Instead we store X-MOZ-LASTACK at the master/parent item instead. That's the reason why a single dismiss on a series dismisses all alarms of the series (I don't have the bug at hand). Since the parent/master item need not have a VALARM specified at all, I've removed it from the VALARM component, and store it in the VEVENT/VTODO component (bug 389251).

Comment 3

[Daniel Boelzle [:dbo]]

We might consider spending more types of lsatAck properties, e.g. X-MOZ-ABC-LASTACK, but I am not sure if there's really the need. If you e.g. specify an email or sms alarm, those aren't acknowledged by lightning/sunbird.

Comment 4

[Bas van den Bosch]

Perhaps we do bloat the calendar-data a bit more but don't we get a lot more lookups (using the item for details and having to lookup the parent for alarm-data)? Also, we'll probably having lots of exceptons to recurring tasks when we're able to set single instances of recurring tasks to completed. A bit more data in the ics doesn't hurt that much imho seeing the memory-problem was somehow fixed for the largest part. Just my thoughts, I'm no programmer...

Comment 5

[Daniel Boelzle [:dbo]]

(In reply to comment #4)
> Perhaps we do bloat the calendar-data a bit more but don't we get a lot more
> lookups (using the item for details and having to lookup the parent for
It's not only because of more data. The lookups are cheap, but reading/parsing the exceptions is expensive. I suspect it's one of our pain points even today (storage provider needs to do extra queries for every exception).

> alarm-data)? Also, we'll probably having lots of exceptons to recurring tasks
> when we're able to set single instances of recurring tasks to completed. A bit
Setting single tasks to completed of course matches the same problem, but this doesn't mean we should follow that for alarms, too.

> more data in the ics doesn't hurt that much imho seeing the memory-problem was
> somehow fixed for the largest part. Just my thoughts, I'm no programmer...
I don't see that fixed yet, I can still experience it and even if we have it fixed, it still costs performance parsing all those.

Finally while we're at it, I can only repeat that I don't like that alarm dismisses are stored inside the VCALENDAR data. Alarm dismisses are personal, and shouldn't go into shared calendars. I know the intent has been to support the "multiple lightning/sunbird instances use a single shared webdav calendar", so if you dismiss an alarm on one instance, you don't need to dismiss it on another instance/profile. This works well for lightning/sunbird, but doesn't if you look at the shared webdav calendar e.g. from Outlook (because it's an X-MOZ prop, not standardized at all).
For the stated reasons, I think it's most conservative to store the alarm dismisses off-site of the calendar data, i.e. in the profile only, leaving the calendar data untouched when dismissing an alarm.