[Kolab-devel] imap search operation costs

[Martin Konold]

Am Freitag, 16. Juli 2004 10:27 schrieb Stuart K. Bingë:

Hi Stuart,

> > Yes, this was what I hoped you where doing.
> >
> > What about the idea to add the iuid already to the extended fb lists
> > objects?
>
> This becomes a bit tricky in that the contents of the calendar mailbox may
> have changed between when freebusy.php generates the f/b list and when the
> f/b viewer displays them, due to freebusy.php caching the lists, etc.

I meanwhile I read multiple times that you are afraid of invalid/outdated 
iuid's :-)

Fortunately the semantics of the imap uid(*) makes this no big deal but 
actually helps to avoid some pitfalls and makes the final code much _simpler_ 
not more difficult.

Due to the fact that the server generated extended freebusy lists are very 
current it is actually really hard to trigger the miss but anyway we must be 
prepared to handle this case.

So what to do in the case the IUID does not exist anymore? (this is equivalent 
to a modified or deleted event)?

In this case the semantic of the freebusy viewer is broken. or better say 
incoherent.

In case the user clicks on an event he expects the corresponding event to be 
displayed.

If the event got modified e.g. the date got shifted to one week later the new 
object is not necessarily the data the user wants to see in her context.

If the event got deleted (euid search is empty) you want to present some error 
message?!

Now think about the following proposed algorithm:

Provided you want to keep the UI simple and more familiar to normal GUI 
applications while hiding the latency/coherency issues of the webapplication 
you can simply shortcut and use the following imho superiour, simpler and and 
more consistent solution:

1. Retrieve the extended fb list (with the iuid in addition to the euid) from 
the server.

2. Display the fb view to the user.

2. when user selects an object you immediately know the iuid and you fetch the 
corresponding iuid from the server.

2.1 if this succeeds (this is the very common case > 99.9%) you are done.

2.2 if this does not succeed (the rare case) you simply start from point 1
(the beginning) in order to get an updated fb list generated from the server 
and an updated display with all the recent changes.(**)

I don't think it can become easier than that.

Do you agree with me?

> If we were to do a IUID->EUID mapping then we'd best do in in the free/busy
> viewer and let freebusy.php deal with EUIDs.

No, it is much better done while the freebusy.php has to parse _all_ messages 
anyway. IMHO it is a trivial addition to the freebusy.php script.

(*) It is important to keep in mind that the imap uid is in contrast to the 
euid not a random number but has a semantic (it is strongly monotoneous). 
This semantic can be used to write efficient clients and is the key to 
scalability in the IMAP protocol.

(**) I dont think that it is a good idea to shown an error message in this 
case. People are used to the fact that the data can be updated implicitly.

Yours,
-- martin

Dipl.-Phys. Martin Konold

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold at erfrakon.de