Toltec connector and exceptions to recurring events

[Reinhold Kainhofer]

Am Dienstag, 31. Mai 2005 01:56 schrieb Helge Hess:
> > That workaround won't work, since lots of places use a structure like
> >
> > QString uid=....;
> > Event *event = calendar->event( uid );
> > createObject(event->summary(), ....);
>
> Hm, yes, but (note: I don't know how dynamic C++ or the Kontact API
> is here) couldn't the Event be some subclass of Event which actually
> is a collection?

That's how the solution would probably be implemented. 

> There would be two cases:
> a) code which can't deal with multi-events
> b) code which can
>
> In the a) case you would use the "master event" for determining the
> subject and other core properties.
> While for b) the consumer could process event-specific properties
> (using an [event conformsToProtocol:@protocol(MultiEvent) in ObjC to
> check for MultiEvents ;-)

Sure, but unless all places from a) are eliminated, things  will just be 
inconsistent (e.g. events appearing with summary "XY" in one place, while in 
another spot, it has the summary "AB" of the original event).


> I have the impression that this would allow for a step-by-step
> approach to get rdate support.

Ahm, we're not talking about rdates here. RDATE is rather simple (and 
KOrganizer will support this in KDE 3.5; Actually KOrganizer from KDE 3.5 
will  support the whole range of RRULE, EXRULE, RDATE, EXDATE defined in rfc 
2445). RDATE is just an additional recurrence at a time that cannot be 
expressed by a rule. it's basically a "this event occurs every friday, oh and 
also on March 1 at 15:00". There's no separate event involved, while 
RECURRENCE-ID has an additional event where every property (summary, 
description, location, attendees, duration, attachments,etc.) is independent 
from the original event.

> > You see, lots of places explicitly depend on the assumption that
> > only one
> > unique (possibly recurring) event is associated to one UID. I guess
> > it would
> > take quite a lot of work to get rid of this in kde-pim.
>
> RID is somewhat important for us because its in my understanding the
> iCalendar approach to represent our way of dealing with recurrences.

Okay. So you imagine an event that start on June 1, 2005 and 14:00 recurs 
every Wednesday for 4 times. In OGo you store this as four events, that occur 
on
-) June 1, 2005, 14:00
-) June 8, 2005, 14:00
-) June 15, 2005, 14:00
-) June 22, 2005, 14:00

What happens to the event on the server if you change the start date of the 
June 15 event to June 13, 10:00, and you also change the summary? Will the 
recurrence still be detected as such? 

The iCalendar way would be that the original event has an RRULE:

UID:1234567890
DTSTART;TZID=CEST:20050601T140000
RRULE:FREQ=WEEKLY;COUNT=4

and when you change the start date of the June 15 event, the original event 
would get an EXDATE:

EXDATE;TZID=CEST:20050615T140000

And a newly created event would have the new summary and:

UID:1234567890
RECURRENCE-ID:20050613T100000
DTSTART;TZID=CEST:20050601T140000

(Or something like that. I'm writing down these things from my head, so I 
might get some details wrong).

Cheers,
Reinhold

PS: Is ogo.fruitsalad.org down?
-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20050531/369e58c3/attachment.sig>