"Last action" fields

Reinhold Kainhofer reinhold at kainhofer.com
Thu Oct 7 18:02:39 CEST 2004


On Thursday 07 October 2004 17:28, David Faure wrote:
> On Thursday 07 October 2004 15:08, Bernhard Reiter wrote:
> > We do not have last-action in the specs yet,
> > so let us make some progress here.
> >
> > Please all  says again if we should add this
> > to the spec and you agree with it.
> > Then David can add it.
>
> I'm fine with adding it and ignoring it in Kontact, but that's probably not
> what we want for full interoperability.
>
> The real question is whether we need to change korganizer's invitation
> handling or not. 

KOrganizer's old invitation handling mechanism still has something like that. 
It only stores the last action in it's own config file, rather than in the 
calendar (as it should be). Actually, this has cause me some headaches 
already, because it prevented cancel messages being sent to removed attendees 
(since the invitation was never sent out by the old groupware code, but by 
the new, but the old one assumed it'sthe only groupware code in 
korganizer...)
The new code (which is used if the "Use groupware communication" checkbox is 
enabled), never had something like that.

> > Note that Outlook will ask the user for this case and give a
> > triple choice:
> >  Mail on the the new attendees.
> >  Mail all
> >  Do not mail the update.
>
> OK.

KOrg only asks "Mail" or "dont mail" when adding attendees. When removing 
attendees, korg asks if cancel messages should be sent to the removed 
attendees, and then it asks if the changes should be sent to the other 
(non-removed) attendees.

> > As explained before we cannot be sure to see all revisions of
> > an event, because other clients might work on it.
> > So I could imagine a comparision to the change date and the
> > last-action-date that probably is a good hint.
>
> Well, but we can't just make up algorithms as we want here, if this
> is built into Outlook, can we?

The icalendar spec is quite clear on this issue: The event with the higher 
revision number always wins. Changes can (shall) only be made by the 
organizer, anyway. So, basically, all icalendar-based apps will probably just 
look at the revision.


Reinhold
-------------- 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/20041007/c3cf2046/attachment.sig>


More information about the format mailing list