[Kolab-devel] imap search operation costs
martin.konold at erfrakon.de
Fri Jul 16 23:14:56 CEST 2004
Am Freitag, 16. Juli 2004 10:27 schrieb Stuart K. Bingë:
> > 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
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
In case the user clicks on an event he expects the corresponding event to be
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
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
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.
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
More information about the devel