"Last action" fields

[Bernhard Reiter]

On Thursday 07 October 2004 18:02, Reinhold Kainhofer wrote:
> On Thursday 07 October 2004 17:28, David Faure wrote:
> > On Thursday 07 October 2004 15:08, Bernhard Reiter wrote:

> > > 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.

Those actions would be triggered as a diff from what has happened
last time (at least if I understand this correctly).
As with the nature of Kolab's design, as a client you cannot be sure
that you have seen or will be able to retrieve the last revision
of the event. You can only know that you have an updated one,
but you know that already without a revision field.

David is refering to how outlook operates and outlook might
keep that information in a different way.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20041008/6888d761/attachment.p7s>