On Sun, 2011-09-18 at 13:07 +0200, Ove Kåven wrote:
[add EXDATE to parent event for detached recurrences]
> Is there any reasonable way SyncEvolution could do that conversion, so I
> won't have to keep scratching my head trying to remember which was the
> original, superseded event?
Let's see...
In the CalDAV backend, all related VEVENTs sharing the same UID are
available together. Adding a detached recurrence will automatically mark
the parent event as updated, so it will be stored anew in the local
storage. It wouldn't be too hard to add some code which copies all
RECURRENCE-IDs into EXDATEs.
However, conceptually this is a hack. This conversion belongs into the
translation layer between CalDAV (one item per UID) and the
engine/Maemo5 calendar (one item per VEVENT), if and only if that other
backend doesn't support UID. But at that level semantic conversions
aren't easy anymore, because that level doesn't know anything about
iCalendar.
Here's a possible solution which is perhaps not too hideous:
1. introduce a new RECURRENCE-IDS field: an array of time stamps,
similar to EXDATE
2. map it to an iCalendar 2.0 X-SYNCEVOLUTION-RECURRENCE-ID
property which is only used internally
3. the CalDAV backends and ActiveSync backends create such
properties in the parent VEVENT
4. the Synthesis engine passes it through to the Maemo 5 backend
(thanks to points 1 and 2)
5. the Maemo 5 backend treats it like EXDATE when storing
Retrieving an updated parent event from the Maemo 5 backend then will
add normal EXDATEs to the CalDAV server, which is redundant, but not
wrong.
How does that sound?
--
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
