Toltec connector and exceptions to recurring events

Fri May 27 15:27:11 CEST 2005

Thanks for the response!

Just so I'm clear, are you suggesting that the Toltec connector should
be doing something different?  Or are you suggesting that the
case I described is "rare" and so isn't a concern?  

Asking this in another way, suppose I need to import the following 
event generated by Apple's iCal and convert to a kolab data format:

BEGIN:VEVENT
DURATION:PT1H
ATTENDEE;CN="Bubba Smith":mailto:bubba at collison.net
LOCATION:My Office
DTSTAMP:20050527T124609Z
UID:263E7ABC-CEAD-11D9-96DB-000A959D1452
SEQUENCE:4
ORGANIZER;CN="Alan Collison":mailto:alan at collison.net
STATUS:CONFIRMED
DTSTART;TZID=US/Eastern:20050527T160000
SUMMARY:Test Event
DESCRIPTION:Test of recurring event.
RRULE:FREQ=WEEKLY;INTERVAL=1
END:VEVENT
BEGIN:VEVENT
DTSTART;TZID=US/Eastern:20050603T160000
LOCATION:Boardroom
UID:263E7ABC-CEAD-11D9-96DB-000A959D1452
RECURRENCE-ID;TZID=US/Eastern:20050603T160000
DURATION:PT1H
END:VEVENT

What should this event look like in kolab's data format?  Also, this example
of an Outlook event (actually, it's an update notice to a recurring
event indicating a change in location for a single instance):

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:(GMT-07.00) Mountain Time (US & Canada)
X-MICROSOFT-CDO-TZID:12
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=4;BYDAY=1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20050502T210742Z
DTSTART;TZID="(GMT-07.00) Mountain Time (US & Canada)":20050523T153000
SUMMARY:Updated: Recurring event test step 1
UID:040000008200E00074C5B7101A82E00800000000D026C9E61F4FC501000000000000000
 01000000052C7EFF3B688FF4F95A3B5113FE6951C
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Collison,
  Alan":MAILTO:alan at collison.net
ORGANIZER;CN="Collison, Bubba":MAILTO:bubba at collison.net
LOCATION:Your office
DTEND;TZID="(GMT-07.00) Mountain Time (US & Canada)":20050523T160000
DESCRIPTION:Moving location to "Your office" for one occurance on 5/23.  
RECURRENCE-ID;TZID="(GMT-07.00) Mountain Time (US & Canada)":20050523T15300
 0
SEQUENCE:0
PRIORITY:5
CLASS:
CREATED:20050502T210743Z
LAST-MODIFIED:20050502T210743Z
STATUS:CONFIRMED
TRANSP:OPAQUE
X-MICROSOFT-CDO-BUSYSTATUS:FREE
X-MICROSOFT-CDO-INSTTYPE:3
X-MICROSOFT-CDO-INTENDEDSTATUS:FREE
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-OWNERAPPTID:897734613
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT00H15M00S
END:VALARM
END:VEVENT
END:VCALENDAR

What should the final kolab data for the origianl event + the update
look like?

Neither of these examples is a rare occurrence: changes in location, time, 
or some other detail of individual instances of a recurring event
happen all the time.  So, what I'm trying to understand is how these
cases are intended to be handled in kolab.

If these cases can be handled in the kolab format, it's not clear to
me how for all variations, particularly since only one 'recurrence' tag
is allowed (even though the iCalendar RFC allows for multiple
RRULE's). If they cannot be handled
consistently, then that seems like a major compatiblity issue with
existing calendar clients.  I'm hoping I just don't understand
something about the kolab storage format :)

Alan

---- Bernhard Reiter <bernhard at intevation.de> wrote:
>
> As far as I know writing of recurrent events has not been 100% implemented
> in Toltec. There are many cornercases.
> We cannot completley exclude that we still have flaws in the data format,
> but they will only matter in rare cases. 
> 
> Bernhard
> 
> On Thursday 26 May 2005 16:10, Alan J Collison wrote:
> > I was hoping someone could clarify the following observed behavior:
> >
> > Using Outlook with the Toltec connector and connecting to Kolab,
> > I created a recurring event.  I then changed the location for
> > one instance of the recurring event, leaving all the others the
> > same.  Since the Kolab data format does not support RECURRENCE-ID
> > (or some equivalent), I was expecting that perhaps the single
> > series of recurring events would be broken up into 2 parts:
> > the original series without the one exception and a new single
> > event corresponding the the instance with the new location.
> > I see no other way to handle this with the Kolab data format.
> >
> > However, what happened was that an exception was added for that
> > one instance and no new event was created.  Looking at the
> > data, it's apparent that Toltec is storing a RECURRENCE-ID (or equivalent)
> > and information about the exception to the recurring series of events. So,
> > in Outlook, everything looks o.k.  However, if I use another
> > client which relies on the Kolab data, it would see something
> > different I think: it would see a recurring series of events with
> > a hole in the series on the date of the specified exception.
> > In other words, the event ocurring on the day of the exception has
> > effectively disappeared, even though that exception is not a cancellation
> > of the event instance.
> >
> > So, what I am wondering is which of the following is true:
> >
> > 1. This is considered a problem/limitation in the kolab
> >    data format
> >
> > 2. This is considered a problem in the behavior of the Toltec
> >    connector
> >
> > 3. This is not considered a problem (and if so, why?) :)
> >
> > Alan
> >
> >
> > _________________________________________________________
> > XO Hosting and Email: Great Service, Great Features, Great Support!
> > http://register.cnchost.com/offers/referral/referrer=collison.net/
> >
> >
> > _______________________________________________
> > Kolab-users mailing list
> > Kolab-users at kolab.org
> > https://kolab.org/mailman/listinfo/kolab-users
> 

_________________________________________________________
XO Hosting and Email: Great Service, Great Features, Great Support!
http://register.cnchost.com/offers/referral/referrer=collison.net/