On Fri, 2011-09-30 at 15:13 +0200, Ove Kåven wrote:
> Den 29. sep. 2011 13:17, skrev Patrick Ohly:
> > 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?
>
> Hmm. I suppose that'd work (though I'd have to learn what APIs to use to
> make the backend convert these properties).
Your backend gets an iCalendar VEVENT specifically formatted for it by
the engine. It will be possible to tell the engine that RECURRENCE-IDS
field entries are to be mapped to the regular EXDATE when formatting for
your backend.
Your backend needs to set SynthesisInfo::m_backendRule to a unique
string (MAEMO?) in a specialized version of getSynthesisInfo() and the
iCalendar 2.0 profile needs to take that into account.
> It'd perhaps be better if
> the added EXDATEs could be automatically stripped later, but if you
> don't think they're going to hurt...
Hmm, the inverse operation could strip out redundant EXDATEs again, but
I am not sure whether it is worth the effort.
> I've gotten another problem with recurrences, though; after changing
> some stuff around in Google Calendar, including rescheduling a single
> instance of a recurrent weekly appointment to a different day, I get the
> fatal error "new CalDAV item does not have right RECURRENCE-ID". I
> suppose that might also be related to Maemo 5 not storing RECURRENCE-IDs?
Yes, that should be it.
The code is in CalDAVSource::insertSubItem() in CalDAVSource.cpp:
if (subid != knownSubID) {
SE_THROW("new CalDAV item does not have right
RECURRENCE-ID");
}
I bet subid is empty here. Instead of bailing out, the CalDAV source
could attempt to silently restore the right icalproperty. It's a bit
tricky because the knownSubID is the date-time value without the
corresponding time zone (like EDS does it). One would have to find the
dtstart of the parent event and use its time zone + TZID.
--
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
