Fwd: RE: recurrences counted from the back

[Jesse Mundis]

My comments on recurrences are included after the quoted material below.

Recently on the list, Joon and Martin said:

> From: Joon Radley <joon at radleys.co.za>
> To: 'Martin Konold' <martin.konold at erfrakon.de>, kolab-format at kolab.org
> Subject: RE: recurrences counted from the back
> Date: Thu, 10 Aug 2006 12:57:22 +0200
> Thread-Index: Aca8CRPTe4vM9f5/TFyVHZ1Zr4Ez8AAXC2gg
> 
[...]
>
> > > 4. recurrances
> 
> The recurrence is a big and ugly monster. There are a number of factors that
> limits what can be done with recurrences. 
> 
> Firstly the Outlook recurrence object changes from version to version as do
> the support for what recurrences are supported. So you can only define so
> many recurrence rules until you need to create new objects. Outlook 2000
> supports less than Outlook 2003 and I am sure that Outlook 2007 will bring
> brand new complications to this issue.
> 
> Secondly due to the nature of recurrences and exceptions, the definition of
> rules can become very complicated. It will take a lot of effort to define
> the rules and then some more to make them work with all the clients.
> 
> > Proposed solution:
> > 
> > allow not only for one event tag in the 
> > application/x-vnd.kolab.event but an 
> > ordered list of multiple events.
> 
> So from what I understand you want to have one object on the client and
> multiple objects on the server. They are then all linked via the
> application/x-vnd.kolab.event tag set on each of the objects on the server.
> I can only assume that all the objects will be in the same folder and that
> each object will have to contain the tags of all the other related objects.
> 
> Could you please provide the synchronization logic for this scheme between
> the client and the server.

I'd like to suggest we re-examine the idea of adopting the iCal "RECURRENCE-ID"

   http://www.faqs.org/rfcs/rfc2445.html - Section 4.8.4.4

for inclusion in the Kolab data format, and eventual support in the Toltec
connector as well.  This isn't a panacea for all of the recurrence woes
being discussed here, but at the moment I'm concerned with one in particular.

The case described eloquently by Alan Collison and Reinhold Kainhofer
over a year ago in this thread:

   http://kolab.org/pipermail/kolab-format/2005-May/thread.html#555
   "Toltec connector and exceptions to recurring events"

Essentially, there is a very common use case where a user sets up a
recurring event (let's say a weekly meeting in room A on Wednesdays)
and then at some point in the future needs to move one specific instance
of this meeting to Room B.  Other than the location change on this
one specific day, the event is unaltered.  Outlook handles this fine,
and via the "RECURRENCE-ID" the iCal data format can describe this
situation too.  However, the only way I've found to describe this in the
Kolab data format is to introduce an exception to the recurring event,
then create a new, single-occurrence event that overlaps in time with the
exception.  This is less than ideal, as we lose any sense of relationship
between the original event, and the location-changed instance.

Since this is an unacceptable "solution" (breaking the event into two
different events), Toltec rightly doesn't do that.  It does introduce the
exclusion for the changed date, but it has no way to record the altered
information in the Kolab XML.  As a result, the "Room B" instance is
lost completely in the Kolab XML, and only preserved in the TNEF-encoded
attachment.  Everything looks fine on the Outlook side, but we currently
have data-loss on the Kolab side.

iCal's "RECURRENCE-ID" is a ready-made solution for this problem.
It essentially allows one to specify an instance of a recurrence
rule, while maintaining the same uid.

If anyone else in the community has a different idea, I'd like to hear
it and get a discussion going.  But even more than that, I'd like to
see forward motion and development progress on implementing some sort
of solution to this data loss scenario.  It was discussed over a year
ago and still exists in the current data format.

Thanks for listening.

Jesse


-- 
Jesse Mundis
jesse at sw.xo.com

"Trading quality of life for expediency only allows us to fit more
dissatisfaction into our lives."