From b9f080cd7b29b281da1cb56eca36d3e6f1a0172f Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Wed, 25 Sep 1996 16:41:43 +0000 Subject: Move Chris Newman's criticism here. svn path=/trunk/; revision=140 --- imap.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) (limited to 'imap.c') diff --git a/imap.c b/imap.c index 5cc5e054..902688f0 100644 --- a/imap.c +++ b/imap.c @@ -9,6 +9,50 @@ programmer: Eric S. Raymond description: IMAP client code +Chris Newman, one of the IMAP maintainers, criticized this as follows: +------------------------------- CUT HERE ----------------------------------- +On Wed, 18 Sep 1996, Eric S. Raymond wrote: +> 1. I do one one SELECT, at the beginning of the fetch. +> +> 2. I assume that I can pick an upper bound on message numbers from the EXISTS +> reponse. + +Correct. + +> 3. If there is an UNSEEN nnn trailer on the OK response to SELECT, I assume +> that the unseen messages have message numbers which are the nnn consecutive +> integers up to and including the upper bound. +> +> 4. Otherwise, if the response included RECENT nnn, I assume that the unseen +> messages have message numbers which are the nnn consecutive integers up to +> and including the upper bound. + +These will only work if your client is the only client that accesses the +INBOX. There is no requirement that the UNSEEN and RECENT messages are at +the end of the folder in general. + +If you want to present all UNSEEN messages and flag all the messages you +download as SEEN, you could do a SEARCH UNSEEN and just fetch those +messages. + +However, the proper thing to do if you want to present the messages when +disconnected from the server is to use UIDs. To do this, you remember the +highest UID you have (you can initialize to 0), and fetch everything with +a higher UID. Ideally, you shouldn't cause the SEEN flag to be set until +the user has actually seen the message. This requires STORE +FLAGS SEEN +for those messages which have been seen since the last update. + +The key thing to remember is that in IMAP the server holds the +authoratative list of messages and the client just holds a cache. This is +a very different model from POP. +------------------------------- CUT HERE ----------------------------------- + +A problem with this recommendation is that the UID commands don't exist +in IMAP2bis. Since we want to preserve IMAP2bis capability (so fetchmail +will continue to work with the pre-IMAP4 imapd) and we've warned the user +that multiple concurrent fetchmail runs are a Bad Idea, we'll stick with +this logic for now. + ***********************************************************************/ #include -- cgit v1.2.3