Event UID in the Subject?

[Martin Konold]

Am Dienstag, 13. Juli 2004 17:59 schrieb Bo Thorsen:

Hi,

> I still don't see the point in not doing this.

The point is simply that I dont wan't the regular (normal case) IMAP searches 
on one hand as this causes load on server which limits its scalability. On 
the other hand I want an optimal user experience with optimal user 
visible/feelable speed.

Last but not least redundant data is potentially a problem. (The entity UID 
can _never_ change, so redundancy does not hurt)

Though I have to admit that the server side searches really worry me in this 
case. 

Putting the e-uid in the subject leads to clients abusing the IMAP server as a 
bad implementation of a database server.

Last but not least I can show that in the common case the approach with the 
search is slower and needs more resource for both the (web)client and the 
server. In the end this leads to a less optimal user experience while wasting 
computing resources.

As far as I understood Stuart he intends something like:

1. Read _all_ messages from the calendar folder initially

2. Create a calendar for the user to present (either a webpage or a memory 
representation)

3. User selects some object (e.g. a singe event/appointment)

3.1 The selection is either encoded in the URL or some session variable. As 
far as I understood the Horde Framework gives an ical/xml UID _not_ the IMAP 
uid

4. The next required step is to get the correct message/object from the IMAP 
store.

4.1 As he does not know the imap UID he wants to search on the IMAP server for 
the correct message

4.1.1 This can be done either the _very_ slow way by reading again all 
messages, parsing all messages until the correct message is found.

4.1.2 or via the proposed _much_ faster way by only doing a search on the 
Subject Header (search on the server) and then fetch only the single correct 
message. (*)

4.2 There are only three cases with the described algorithm:

4.2.1 There is a single message with the required ical/XML uid (This is the 
normal case like 99%)

4.2.2 There is no message with the required ical/XML uid because someone 
deleteted the event in the meantime due to concurrent clients working with 
the same imap folder. (This is the rare case about 0.95%)

4.2.3 There are more than a single message with the same required ical/XML 
uid. (This is the extremely rare case < 0.05%) where we require conflict 
resolution(**).
 
5. Message is found (server return the correct IMAP UID) 

5.1. Fetch message from server using the newly obtained IMAP UID.

5.2 Parse message on the client 

6.0 Done!


Stuart: Please tell me if I understood you correctly. If yes, then I will 
continue to describe why the other method  (using the uid mapping) is much 
more efficient, consistent, has better scalability and less error prone.

(*) There is no doubt that 4.1.2 is much faster and puts less load on the 
server than 4.1.1. As far as I understood this is the main performance 
benefit when putting the e-UID in  the Subject header.

(**) I don't want to dive into the issues about conflict resolution here.

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