Hello Ove!
Just going through older emails... do you need some help with this or
are the pointers enough? I could provide a untested patch which changes
the core infrastructure as suggested, as a starting point.
Bye, Patrick
On Fri, 2011-09-30 at 18:41 +0200, Patrick Ohly wrote:
> 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.
>
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
