Extra Header field

[Martin Konold]

Am Montag, 12. Juli 2004 20:00 schrieb Stuart K. Bingë:

Hi Stuart,

> > client cant keep a simple mapping <uid>,<imap-uid> in the session. After
> > all the Horde client must parse every message anyway before it has the
> > complete calendaring information.
>
> This will not be practical, as like I said, the IMAP UID is not constant
> across object modifications. This means I will have to deal with the
> possibility of holding an incorrect UID mapping.

I have the impression that you are not aware of the monotonious nature of imap 
uids. Technically this means that the <uid>,<imap-uid> mapping is a cache of 
the actual mapping on the server. Instead of reparsing it every time you 
simply use the cache.

Q: Why is the usage of the chache save? Any why can you _never_ obtain 
outdated data?

A: Because the imap uid is monotoneous it never reused and new messages always 
get a larger number. In case the cache is not uptodate the server tells you 
immediately that this imap uid is invalid. You than also now immediately that 
you must check for new messages. You then must parse all new message and 
check if the UID is present in one of the new message. In case the UID is 
found you update your mapping and in case the missing UID is not found the 
message is simply not there anymore.

> For example, it may be the case that between when I initially load a
> mailbox and form this mapping, to when I need to load up a specific object,
> something or someone has modified the mailbox and consequently messed up my
> UID mapping, without me even knowing about it.

No, this is not possible as you can easily detect this situation (imap uid not 
available anymore). 

> > In case the caldendar changes while the Horde client has a local
> > representation it has to parse _every_ new IMAP message anyway.
>
> That's true. But if all I want to do is load an object, given its UID, and
> if the UID is stored in a header, I can then perform a SEARCH on the
> mailbox to load the message of interest without having to touch the rest of
> the messages, which are of absolutely no relevance to the operation.

In case you keep the mapping you can _directly_ fetch the message before any 
costly search. In the rather rare case that the message either vanished or 
changed the unsuccessful fetch operation will tell about that and the above 
described algorithm will allow you to find the modified message efficiently. 
As a side effect you are updating the mapping.

> It's only the case that I *need* to reload the entire message box when I'm
> generating a complete listing page.

What is a listing page?

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