Subject: how to quickly get number of new messages?

From: Vadim Zeitlin <[email-masked]>
Date: Mon, 5 Nov 2001 20:13:29 +0100 (CET)

Hello,

 it seems that there is no quick way to get the number of new (i.e. RECENT
and !SEEN) messages in a mailbox using c-client (nor any provisions for
doing it in the IMAP itself) so I find myself forced to do a mail_search()
for such messages just to get their count. This works but isn't
particularly efficient so I'd like to know if I'm missing some obvious and
faster way to do it? It seems so strange that IMAP server always tells the
client about recent messages (both in untagged responses and in reply to
STATUS command) but not about the new ones which are much more interesting
from the client point of view...

 Is there any better way to get the number of new messages? Thanks!
VZ

-- 
------------------------------------------------------------------
 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: Mon, 5 Nov 2001 11:37:46 -0800 (PST)

mail_search() isn't bad.  In fact, that's the way you do it.  In general,
a client is not just interested in knowing how many new messages; it is
also interested in knowing where the new messages are.

The other thing that many clients do is a big fetch (1:*) of flags or
"fast" data via mail_fetch_flags()/mail_fetch_fast() to do a complete
client synchronization of flag state.  That's a one-shot operation;
subsequent operations are just a reference to mail_elt() for the message
since the IMAP server will transmit flags updates and the remainder of the
fast data is static.

Although a big fetch should be avoided on principle, it isn't as bad for
flags or fast as it is for, say, ALL, FULL, or RFC822.  If the client
really needs to know about the flags of messages for some global purposes
(and for more than answering a single question), the big fetch is a
reasonable price to pay.

> from the client point of view...

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

---

From: Vadim Zeitlin <[email-masked]>
Date: Mon, 5 Nov 2001 21:02:35 +0100 (CET)

On Mon, 5 Nov 2001 11:37:46 -0800 (PST) Mark Crispin <[email-masked]> wrote:

MC> mail_search() isn't bad.  In fact, that's the way you do it. 

 Thanks for your reply!

MC> In general,
MC> a client is not just interested in knowing how many new messages; it is
MC> also interested in knowing where the new messages are.

 I agree that you usally want to do something with the new messages
appearing in a currently opened folder (i.e. download them, filter them,
...) but I was thinking more about biff-like functionality. I.e. I'd like
to update the status of the folders shown in the tree and for it would be
nice to avoid doing mail_search() (and ideally even mail_open()) just for
this. In fact, I think that I'll finally use mail_status() nevertheless and
show all recent messages as new ones - although it is, of course, a false
assumption, I think it would still be better than doing mail_search()...

MC> The other thing that many clients do is a big fetch (1:*) of flags or
MC> "fast" data via mail_fetch_flags()/mail_fetch_fast() to do a complete
MC> client synchronization of flag state.  That's a one-shot operation;
MC> subsequent operations are just a reference to mail_elt() for the message
MC> since the IMAP server will transmit flags updates and the remainder of the
MC> fast data is static.

 Again, this is for the folders which are kept opened - I don't want to
keep all folder on the IMAP server opened all the time.

 I'm still curious as to why IMAP STATUS command returns the number of the
recent messages but not the new ones?

 Thanks,
VZ

---

From: Mark Crispin <[email-masked]>
Date: Mon, 5 Nov 2001 12:15:34 -0800 (PST)

On Mon, 5 Nov 2001 21:02:35 +0100 (CET), Vadim Zeitlin wrote:
> I'd like
> this.

There are some optimizations possible.  For example, you can compare RECENT
from UNSEEN in STATUS.  You can also look at the UNSEEN code from EXAMINE
(which points at the first unseen message, not the number of unseen messages)
and perhaps do something different if it disagrees with your assumption.

> In fact, I think that I'll finally use mail_status() nevertheless and

RECENT is an excellent approximation to NEW, particularly if it was obtained
through mail_status().

> recent messages but not the new ones?

Most people care about UNSEEN instead of RECENT or NEW.

---

From: Vadim Zeitlin <[email-masked]>
Date: Mon, 5 Nov 2001 21:29:47 +0100 (CET)

On Mon, 5 Nov 2001 12:15:34 -0800 (PST) Mark Crispin <[email-masked]> wrote:

MC> There are some optimizations possible.  For example, you can compare RECENT
MC> from UNSEEN in STATUS.

 The trouble is that I don't see any useful way to combine them... The only
thing I see is that I can be sure that all recent messages are new ones if
there had been no unseen messages initially in the folder (i.e. on program
startup) and STATUS always returns UNSEEN == RECENT. But as soon as it
doesn't, I'm lost. Am I not?

MC>  You can also look at the UNSEEN code from EXAMINE

 How can I do it using c-client? I didn't find a way to do it (I'm still
using imap2000 BTW).

MC> Most people care about UNSEEN instead of RECENT or NEW.

 I agree that UNSEEN is more important than RECENT... It's just that NEW
seems more important than RECENT as well. In fact, I have some real
troubles in finding any use in having RECENT reply in STATUS at all.

 Thanks,
VZ

---

From: Mark Crispin <[email-masked]>
Date: Mon, 5 Nov 2001 12:34:06 -0800 (PST)

On Mon, 5 Nov 2001 21:29:47 +0100 (CET), Vadim Zeitlin wrote:
> MC> There are some optimizations possible.
>  The trouble is that I don't see any useful way to combine them...

You don't combine them.  You can, however, derive certain conclusions, from
which you can take action.

UNSEEN == RECENT is an assumption that that many messages are new.

UNSEEN > RECENT means that at least delta (the difference between the two)
messages were not read during a session.

UNSEEN < RECENT means that at least delta messages were appended or copied
from another mailbox with the \Seen flag.

>  How can I do it using c-client?

It is delivered to you via mm_notify().

> troubles in finding any use in having RECENT reply in STATUS at all.

UNSEEN and RECENT each define states, either of which is considered "new" by
programs.  NEW defines a combination of UNSEEN+RECENT, and to some people is
rather nebulous; it isn't the messages they haven't read yet nor is the
messages which are new to this session.

In the traditional UNIX mailbox format, UNSEEN is the R flag, and not RECENT
is the O flag.  Consequently, traditional biff type programs usually announce
RECENT rather than NEW, and traditional MUAs usually announce UNSEEN rather
than NEW.