Re: [SyncEvolution] Alarms in the calendar: Evolution vs. vcal
On Thu, 2010-04-01 at 16:18 +0100, Tino Keitel wrote:
On Thu, Apr 01, 2010 at 15:57:53 +0800, Zhu, Yongsheng wrote:
> Hi, Tino
> I can verify your finding. Below bug entry is used to track this issue.
> http://bugzilla.moblin.org/show_bug.cgi?id=10458
> You could track this issue to find the latest information.
> thank you for raising this question.
Thanks for caring about this. I think a solution could be to always
create an ACTION of type DISPLAY,
That's what we do now. I just merge Yongsheng's patch.
with the DESCRIPTION set to the
SUMMARY of the VEVENT.
That is a potential gap in SyncEvolution: it doesn't have "alarm
descriptions" and thus creates/stores slightly invalid iCalendar 2.0
VALARMs without the obligatory DESCRIPTION.
I'm not sure whether this really is a problem in practice. Evolution
doesn't seem to care I assume, otherwise we would expect to have had bug
reports about it before, which is not the case.
I'm not sure whether the problem is solved entirely with Mobical.net,
though. In a simple, relative alarm (15 minutes before event), this was
sent to the server:
BEGIN:VCALENDAR
VERSION:1.0
TZ:+01:00
DAYLIGHT;ENCODING=QUOTED-PRINTABLE:TRUE;+02;20110327T010000Z;20101031T010000Z;;freeassociation.sourceforge.net;Tzfile;Europe;Berlin
BEGIN:VEVENT
LAST-MODIFIED:20100401T161612Z
DCREATED:20100401T161612Z
CLASS:PUBLIC
SUMMARY:custom alarm
DESCRIPTION:custom alarm
DTSTART:20100401T103000Z
DTEND:20100401T110000Z
AALARM:-PT15M;;;custom alarm
DALARM:-PT15M;;;custom alarm
END:VEVENT
END:VCALENDAR
This came back:
BEGIN:VCALENDAR
VERSION:1.0
BEGIN:VEVENT
DTSTART:20100401T103000Z
DTEND:20100401T110000Z
SUMMARY:custom alarm
DESCRIPTION:custom alarm
LAST-MODIFIED:20100401T161623Z
END:VEVENT
END:VCALENDAR
No alarm. Yongsheng, can you investigate further?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.