Extra Header field
martin.konold at erfrakon.de
Mon Jul 12 21:14:06 CEST 2004
Am Montag, 12. Juli 2004 20:00 schrieb Stuart K. Bingë:
> > 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
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
> > 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?
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 format