Toltec connector and exceptions to recurring events
Reinhold Kainhofer
reinhold at kainhofer.com
Tue May 31 02:26:16 CEST 2005
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>
More information about the format
mailing list