On Fri, 2003-02-21 at 08:17, Mark Crispin wrote: > On Thu, 21 Feb 2003, Timo Sirainen wrote: > > I'd like to know how you can make a client efficiently handle sequence > > numbers. If internal message structure contains just the sequence > > number, it has to be updated every time an older message is deleted. > > An obvious structure is a vector of pointers to a msgstruct, indexed by > sequence number. All you have to do for EXPUNGE is byte-blat the pointers > down; that's a memmove() which some processors implement in hardware.
msgstruct -> sequence lookups would then have to find the msgstruct from the array. Not too fast operation really. > You don't have to do the blat to EXPUNGE based upon UIDs, but you have to > have some sort of hash based on UID to locate the msgstruct. Locating a > msgstruct is a much more common operation than expunging one. And creating fetch request for a message is almost as common operation. Doing several slow array lookups there to find out the sequences could well be overall slower than constant UID hash lookups. > There's also the big cost of fetching the UID map at session startup, > which is completely unnecessary unless you have a local cache of the > mailbox state. Evolution has local cache so it wouldn't usually have to do that. More problematic is keeping the message flags updated. Doing FETCH 1:* FLAGS isn't exactly nice, but anything else limits the functionality. Well, I guess updating summaries and virtual folders with SEARCH and fetching flags for only visible messages would be possible. > > I see sequence numbers useful only when you know you want to fetch > > exactly n messages, and even that doesn't work if some of those messages > > just happened to get deleted. > > Nope. You missed the part in which a server can't do untagged expunges > except at certain well-defined points. That doesn't mean that the message still couldn't be physically deleted. If it's gone, server can't send it to client. > > Actually in some situations relying on sequence numbers could even lose > > messages. Suppose a client (maybe a webmail) showing messages 1..10 on > > screen. Next-button would load the next 10. If the IMAP connection got > > closed before next-button was clicked and some of those messages were > > expunged before connection was up again, fetching 10..20 would have > > skipped over some of the unread messages. > > Ah, you're assuming a stupid webmail client which continually reopens new > IMAP sessions for the same webmail session. I was more of thinking a user that waits for a long time before hitting the next button. IMAP connections have to have some timeouts in webmails. Or maybe the connection got closed for some other reason (network problems, server restart). Then again, maybe the whole session should just be invalidated when IMAP connection is lost. That could be a bit problematic with normal IMAP clients as well. It would have to refetch the visible messages to make sure they weren't changed. But what messages exactly? If it couldn't be done by UID, finding them wouldn't be that easy if it's sequence had changed. Message under cursor especially shouldn't change (user could just be hitting delete+expunge). > You can do the same thing with message sequence numbers, and consume less > bandwidth since sequence numbers are smaller than UIDs. OK, so slightly smaller bandwidth usage is second plus in sequences. > > I really don't see when/why sequences are so much better than UIDs. > > Unlike UIDs, you know exactly how many messages are in a sequence, even if > you currently have no information about any of those messages in the > client state. > > With UIDs, you have to download the UID map, which for a moderate to large > mailbox (e.g. 5000 messages) is a substantial amount of data. It will > kill you unless you have a fast network. Try it over CDPD (packet IP over > cellular) sometime. Depends on how client is supposed to be used. If client caches the messages locally it doesn't have to download the whole UID map. And I think that's more common way to use IMAP than using mail clients in phones, PDAs and such. They could of course keep on using sequences if it fits better to their typical use.
