RFC: Splitting the UID concept of tasks and events

[Bo Thorsen]

Hi all,

I just checked a patch into the KDE client that changes the UID concept a 
bit for tasks and events (aka incidences).

The problem is, that many iCal based clients use the UID as a persistent 
handle to other incidences. This works fine until you have access to 
other peoples folders that can have an event with the same UID.

The UID can be identical between two events only when you receive an 
invitation from someone. The event or task saved from that has the same 
UID as the invitation mail. This means, that if you have access to some 
persons calendar and both of you accept an invitation, you will both have 
an event with identical UIDs.

The reason you keep the invitation UID is to match incoming changes to the 
incidence with your local stored copy. So when you get an update mail, 
the old version is updated with the new information - or at least 
replaced with the new version of it.

This is a fundamental flaw in iCalendar, and there is not much to do other 
than to try and work around it.

The fix I came up with is fairly simple: Introduce a scheduling ID. This 
SID is always identical to the UID, unless the event comes from accepting 
an incidence. If this is the case, the SID is the same as the UID of the 
invitation, and UID gets a new unique value.

I have something like this:

Incidence {
  ID getSchedulingID():
    if( hasSID )
      return sid
    return uid
}

This means that for all scheduling, you just use the SID in the future, 
and for all else, keep continuing to use the UID.

Actually there was only four places (I think) in the iCal library of 
kdepim where I needed to change from using the UID to SID, so it's most 
likely not a huge task.

For storing the incidence in iCal, I save the SID in the iCal UID field, 
since the SID is *always exactly* identical to what the UID used to be. 
If UID is not the same as SID (or hasID in the code up there is true), I 
also save a field X-KDE-LIBKCAL-ID that holds the UID. The reason it's 
done like this is that all other iCal applications won't know something 
happened.

I could do the same for the Kolab resource implementation also, but I 
would much prefer to introduce a <scheduling-id> tag instead, that would 
only be present if it is not the same as <uid>. So this change will only 
do something for the incidences you have that comes from accepting an 
invitation.

We currently have four clients.

- The KDE client is quickly done, since I already coded this and have been 
testing it thoroughly over the last couple of weeks.

- AFAIR, Joon once told me that Outlook doesn't use the UID for 
uniqueness, so this part is not a problem. Loading would then mean only 
the SID has a meaning. Saving would mean finding out that this comes from 
an invitation, picking out the UID from the invitation, and saving that 
in SID. And of course come up with some UID.

- Horde would most likely need more or less the same changes as the KDE 
client. I can mail the patch, so you can see exactly what changes was 
done.

- The automatic scheduling code in the server needs to have the same 
changes - save SID on accepting invitations and searching for SID on 
updates.

I don't know how much code is shared between the webclient and the auto 
scheduling stuff, so I can't say if you can share some of the load of 
this.

Implementing the patch took me only some hours. Testing it to be sure it 
worked took a long time. But it's not a big implementation issue.

What do you think about this?

Bo.

(Note: Please keep Till in the CC:)
-------------- 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/20041028/8f8b5025/attachment.sig>