"Last action" fields

[Bernhard Reiter]

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.


On Friday 01 October 2004 18:56, David Faure wrote:
> On Friday 01 October 2004 17:40, David Faure wrote:
> > On IRC today we discussed the fact that Outlook needs some "last action"
> > fields, which we modelled as
> >
> >         <last-action>(invitation-sent, update-sent, or not
> > present)</last-action> <last-action-date>(date or datetime, default not
> > present)</start-date> <last-action-recipients> {
> > <smtp-address>(string)</smtp-address> } </last-action-recipients>
> >
> > <sect2><title>Last Action</title></sect2>
> > <para>The last action taken by the user on a given event can be
> > "invitation-sent" (when the initial invitation was sent), or
> > "update-sent" when an update was sent. The last-action-date tag stores
> > the date and time when this last round of emails was sent, and the list
> > of email addresses in last-action-recipients tells who received those
> > mails. This makes it possible to notice, when adding a new attendee, that
> > we only need to send mail to that attendee.</para>
> > </sect2>

I was immedeately thinking about doing the last action per recipient,
but it well might be that this modelling is enough.

> > However this, alone, doesn't seem to me that it will be useful.
> > If you
> > A1) add a new attendee, and check the last-action-recipients list to see
> > that everyone else got their invitation already, OK, you can mail that
> > attendee alone.

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

> > But if you
> > B1) change the location of the event, but don't send the mail yet
> > B2) add a new attendee, the same code as in A1 is going to send a mail
> > to the new attendee only. Is that OK? Shouldn't the user have a way to
> > flush all pending changes, i.e. inform everyone about the new location?
>
> Hmm. In fact that's independent from B1.

An update all button seems useful, I am currently unsure if outlook has one.

> > It seems to me that optimizations like "only mailing the new attendee"
> > can only be done if there is a way to compare the current revision number
> > of the event with the revision number that it had when the last action
> > was done. Then we can be sure no other change is pending.
>
> Too difficult and not worth it, let's forget about that idea.

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.

> This came from trying to understand Joon's "number of updates" field,
> but he made me realize it's nonsense.
> That "number of updates" is the number of times mails were sent to
> update the event, but neither he nor I can see what it's used for.
> (It can't be for my idea above, if the value of that number when the last
> mails were sent isn't stored).
> If really necessary for outlook, I can add it to the kolab format (and to
> Kontact's Event object) together with the last action stuff.

Joon: Is it okay to leave that out from the spec for now until
we find out what it is used for?
(or did we already find out in the meantime?)


> Same thing for  owner-appointment-id :
> Joon said: "OL creates a random 32 bit integer when an invitation is sent
> out. As far as I know this is used as part of the iTIP transactions. I will
> be storing it in the object, but we may need it later when we handle
> replies from attendees." I really wonder why that is different from the
> event UID...
> The question is, obviously: do we need to generate such a number when
> the first invitation is sent from kontact?
> Does anyone know if (and where) this number is used in iTIP?

No idea, maybe you can ask someone at kolab-devel and kdepim
if they know more?

Bernhard
-------------- 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/20041007/b045d7b2/attachment.p7s>