Greetings,
Alarms for stand-alone clients (Kontact, Lightning, Evolution, etc.) don’t
work well in several ways. The most apparent problem is that the calendar
package doesn’t export alarms in RFC 2445 VALARM (VCal 2.0) format, but
rather the old AALARM/DALARM (VCal 1.0) formats. This is especially bad for
SyncML clients like SyncEvolution that follow the RFC strictly. The attached
patch for v1.4 (rfc_alarms.patch) is what we’ve been using to work around
this. Some of it is taken from the icalsrv package.
The second problem has to do with the way the alarms are stored in
eGroupWare – as items scheduled for asynchronous services. Obviously, one
can’t schedule a job in the past, so past alarms get lost, including if a
Lightning/Sunbird user adds an alarm to a recurring event that begins in the
past. The alarm is simply lost, users miss meetings, and become very unhappy.
I’ve attached a patch that we’re using for that as well
(recurring_alarms.patch) in v1.4.
Third, clients may also provide alarms for tasks, which eGroupWare does not
support. Support for this isn’t too difficult, and I added it in a couple of
hours. I might submit a patch for that once we’ve tested it more.
Finally, some clients use custom attributes to track alarm status. For
instance, Mozilla uses the X-MOZ-LASTACK attribute to track when a specific
alarm was acknowledged and uses X-MOZ-SNOOZE-TIME to track snoozing for
alarms. We’ve had to write some custom code and add custom fields to make
this work.
The first three problems aren’t too difficult to fix, but the fourth is
somewhat ugly. Just some things that might be good to keep in mind as
development goes forward. Perhaps the storage for alarms needs expansion?
Thanks,
–
Peter Goerzen
I.S Development
Hustler Turf Equipment/Excel Industries, Inc.
(620) 327-1180
