"Last action" fields
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
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.
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
> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the format