recurrences counted from the back

Thu Aug 10 01:10:42 CEST 2006

Am Sonntag, 5. März 2006 19:53 schrieb Martin Konold:

Hi,

> Am Donnerstag, 2. März 2006 20:32 schrieb Till Adam:

> > https://intevation.de/roundup/kolab/issue1150 seems to point to a little
> > hole in the recurrence spec.
>
> I agree that the recurrance specification needs some fixing. Actually it is
> missing even more features with regards to recurrances.
>
> I think it can be fixed rather simply without big modifications by mainly
> allowing more values (like negative numbers) and "sub events" for
> describing exceptions)
>
> We now have opened several topics:
>
> 1. privacy flag
>
> 2. imap folder name translation
>
> 3. priority specification
>
> 4. recurrances

sofar this discussion did not continue as I am waiting now since months for 
more input from more people like Joon.

So here comes a concrete proposal:

Lets built upon the existing XML schema for events:

<?xml version="1.0" encoding="UTF-8"?>
        <event version="1.0">
          <!-- Common fields -->
          <uid>(string, no default)</uid>
          <body>(string, default empty)</body>
          <categories>(string, default empty)</categories>
          <creation-date>(datetime, no default)</creation-date>
          <last-modification-date>(datetime, no 
default)</last-modification-date>
          <sensitivity>(string, default public)</sensitivity>
          {<inline-attachment>(string, no default)</inline-attachment>}
          {<link-attachment>(string, no default)</link-attachment>}
          <product-id>(string, default empty)</product-id>

          <!-- Incidence fields -->
          <summary>(string, default empty)</summary>
          <location>(string, default empty)</location>
          <organizer>
            <display-name>(string, default empty)</display-name>
            <smtp-address>(string, default empty)</smtp-address>
          </organizer>
          <start-date>(date or datetime, default not present)</start-date>
          <alarm>(number, no default)</alarm>
          <recurrence cycle="cycletype" [type="extra type"]>
            <interval>(number, default 1)</interval>
            {<day>(string, no default)</day>}
            <daynumber>(number, no default)</daynumber>
            <date>(number, no default)</date>
            <month>(string, no default></month>
            <range type="rangetype">(date or number or nothing, no 
default)</range>
            {<exclusion>(date, no default)</exclusion>}
          </recurrence>
          {<attendee>
            <display-name>(string, default empty)</display-name>
            <smtp-address>(string, default empty)</smtp-address>
            <status>(string, default none)</status>
            <request-response>(bool, default true)</request-response>
            <role>(string, default required)</role>
          </attendee>}

          <!-- Event specific fields -->
          <show-time-as>(string, default busy)</show-time-as>
          <color-label>(string, default none)</color-label>
          <end-date>(date or datetime, default not present)</end-date>
        </event>

As we have encountered before the recurrance/exclusion attributes in the above 
schema are not expressive enough. E.g. we cannot express the following kind 
of event which is possible in the OL GUI.

There shall be a board meeting every Friday with persons A, B and C at 14:00 
CEST except at Sep. 8th the meeting is postponed to 16:00 CEST and on Oct. 
6th person C does not participate but person D is coming instead.

Such events are allowed in the Outlook GUI and Kolab users rightfully expect 
that the Kolab XML format is able to handle this kind of events.

Proposed solution:

allow not only for one event tag in the application/x-vnd.kolab.event but an 
ordered list of multiple events.

In this case the first event in the xml document would describe the already 
supported weekley recurrance while excluding Sep. 7th and Oct. 6th. 

In addition two other events are added to the same xml document:

The second event describes the Sep 8th meeting and the third event handles the 
change in participants for Oct. 8th.

This is only a small change to the existing xml schema (allow for multiple 
event tags in a single xml document of type application/x-vnd.kolab.event.

In addition this update would allow for nice and simple support for 
private/encrypted(*) events.

What do you think?

Regards,
-- martin
(*) Typicall the first event is unencrypted and contains the public data like 
begin/end date and recurrances. Following events contain the 
private/encrypted data like summary and location. Implementing the encryption 
on the event level instead of the individuals tags is much more efficient 
with respect to size/cpu/speed and memory.

Regards,
--martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker