Subject: Unable to check Recent flag of a new message with c-client.

From: "Scot W. Hetzel" <[email-masked]>
Date: Wed, 3 May 2000 15:43:21 -0500

I am trying to add IMAP support to ELM 2.5.3 with the c-client library
(UW-IMAP 4.7c1).  Currently, it is working with reading/copying/moving
messages on the IMAP server.

The problem that I am currently trying to solve is that for some reason the
RECENT flag is reset before the message status check, thus ELM is showing
the message with a "O" status instead of a "N" status.

When I use gdb on the elm binary and set it up as follows:

break newmbox.c:1200                    <- line 1200 is "if(mess->recent >
0)"
condition 1 mess->recent > 0

it doesn't stop processing messages when a new message is received for the
mail account.

Could it be that my message headere retreival code is reseting the RECENT
flag on the IMAP server?

How does pine retreive the message headers & flags from the IMAP server?

Thanks

Scot
----------

loop until we read last message {
            :
            Code to retreive message headers
            :
                /* These routines are used to get the flags of the message:
                 * SEEN, RECENT, DELETED, ANSWERED, FLAGGED
                 */
                sprintf(dnumber,"%ld",fbytes);
                mail_fetchfast(stream,dnumber);

                mess=mail_elt(stream,fbytes);

                current_header->imap_msgno = fbytes;
                current_header->imap_size = mess->rfc822_size;
                if(max_imap_msg < fbytes) max_imap_msg = fbytes;
                strcpy(current_header->mailx_status, "      ");
                mx_offset = 0;
                if(mess->seen > 0) {
                  current_header->status |= SEEN;
                  current_header->mailx_status[mx_offset] = 'R';
                  mx_offset++;
                }
                if(mess->recent > 0) {
                  current_header->status |= RECENT;
                } else {
                  current_header->mailx_status[mx_offset] = 'O';
                  mx_offset++;
                }
                if(mess->deleted > 0) {
                  current_header->status |= DELETED;
                  current_header->mailx_status[mx_offset] = 'D';
                  mx_offset++;
                }
                :
}

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Wed, 3 May 2000 13:55:38 -0700 (PDT)

Scot -

For performance reasons, I strongly recommend against doing a per-message
mail_fetchfast(); instead, you should do an aggregate mail_fetchfast() for all
the messages in the mailbox.

Only the first mail_open() call that sees the recent message(s) will have the
message(s) marked as recent.  So, if you are somehow doing more than one
mail_open(), the subsequent ones won't show recent status for those messages.

-- Mark --

---

From: "Scot W. Hetzel" <[email-masked]>
Date: Wed, 3 May 2000 16:31:03 -0500

From: "Mark Crispin" <[email-masked]>
> the messages in the mailbox.
Do I even need the mail_fetchfast call before checking the message flags?
What is this routine supposed to do?

I commented it out, and it didn't seem to have an effect on the message
flags (after fixing the below problem).

NOTE: the elm2.5.3 imap patch I am working on is based on C Taylor elm2.4
imap patch.

> mail_open(), the subsequent ones won't show recent status for those
messages.
That was the problem, I was calling a routine twice that was using
mail_open().  Commented out the first call and now the new status of a
message is showing correctly.

thanks.

Scot

---

From: Mark Crispin <[email-masked]>
Date: Wed, 3 May 2000 14:40:16 -0700 (PDT)

> flags (after fixing the below problem).

mail_fetchfast() loads the cache of message flags, sizes, and internal date.
It's preloaded in the local mailbox case, but is not in the IMAP case.

If you use the ENVELOPE structure to build your MUA's browser lines, then
mail_fetch_structure() will also load the cache.  So you don't need to do
mail_fetchfast() in that case.

mail_fetch_structure() also works a lot better/faster if you do deferred
loading of your MUA's browser lines.  That is, don't get the data for an MUA
browser line until it's actually time to display it.  The result is much
better real time performance than doing a huge mail_fetchfast() and especially
a single mail_fetchfast() for each message.