Event UID in the Subject?

[Bernhard Reiter]

On Tuesday 13 July 2004 09:23, Bo Thorsen wrote:
> Martin, there is no way in hell it can ever work to use the IMAP UID as
> the event/contact/... ID.

Martin never proposed that.

> Stuart, I agree with David, that if it helps speed up things for you, then
> we will put the event UID in the subject. 

It probably slows down lookup in the normal case:

From the conceptual point of view the following happens:

      1. read all emails to build up the event page
	(you need to read all, because of recurring events that are
	old, but display today.)
       Then you gain a (event uid <-> imap uid) mapping and a last imap uid.
       You create a webpage and in each link  you want to be
	specific about an event you place
                  1  those (e <->i) 
         and in the session the imap uid.

What Martin proposes:
      2. Somebody clicks on this specific event:
	You try the  imap uid from (e<->i), 
		normal case (98%): you get the right message
	        rare case (2%): the imap uid is gone
      2b (rare case):
         Now you get need to find the new imap uid
        and request the new messages (bigger than "last imap  uid).
        It is true that in most cases of this rare event you
        want to show the users that other stuff changed, too,
       so parsing the few new messages seems fine here.
      Now you have a new imap id for your event id
	(and also a new last imap id).

Stuart proposed instead:
       1. as above but only save (even uid) in the link.
	2. Somebody clicks on the specific event,
        you search for it  in the subject over all emails on the folder.
       Getting the imap id.
       3. You get the email for the imap id, if not because
	it changed meanwhile, go to 2.

The latter way poses much more load on the server 
in the common situation, as a search is always required.
This search can be saved in the common case with Martin's
proposal.

The question to get further with this is:
     How rare is the rare case?
    How much effort is it in horde
     to save (e id <-> i id) in event specific link
     and the last imap id in the session?

Stuart, what do you think?

>  In the current resources I've worked on, I have added a
> dictionary that provides event ID to mail identification (KMail calls
> this identification serial numbers). Having the UID in the subject would
> help when the server synchronization updates a mail with one of our
> events though.

This is the rare case and indeed, when the event changed
and you do not want to parse all again or only all new emails,
a search for the subjects of newer emails would speed up that situation.
The question is: How often does this rare event occur?
When an event just got changes under you, in most situations
the user will want to have a fresh complete overview, because
the surroundings will have changed, too.

On the other hand, Martin's suggestion should be used for the common
case anyway, otherwise we are hit by the performance hit.
  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/20040713/4a01e3c1/attachment.p7s>