Subject: Re: How do I determine number of unseen and deleted message guickly

From: "Mark A. Keasling" <[email-masked]>
Date: Wed, 1 Jun 1994 11:40:56 +0900 (JST)

On Tue, 31 May 1994 19:01:09, Mark Crispin <[email-masked]> wrote...
> Once you have done a mail_search() to get the initial count of deleted 
> and unseen messages, you can keep track of the changes in message status
> caused by your application.  This doesn't help you with shared formats 
> such as tenex and MTX which allow multiple simultaneous flag updates, but 
> perhaps you can do the mail_search() update on a slower clock to fix up 
> any cache inaccuracies.

That sounds like a reasonable approach.  Before, I was using the
mail_fetchstructure() and then mail_elt and examining the MESSAGECACHE for
this information as documented in Internal.doc.  Since all of the envelopes
have been fetched already to build list items, would it be better in this
case to use mail_fetchstructure() and mail_elt()?

> 
> What is of greater concern is why the mail_search() is taking so long.  
:
> this isn't an issue with your application.  I'd suggest turning on IMAP 
> telemetry (via the OP_DEBUG flag in the mail_open() call) and logging it 
> (from mm_dlog()) into a file.  Then look to see if there is anything 

I'll try this to see what comes out.

> I suspect that your server is swapping itself to death;

This is the most likely cause.

> an 8MB system is not a reasonable configuration in this day and age.

I couldn't agree more.

-- Mark Keasling
   AIR Company LTD, Nishikawa Mitsui Bldg, 1-3-14 Kitahama, Chuo-ku, Osaka 541
   email: [email-masked]      phone: +1 81 6201 4307    fax: +1 81 6201 2107

---

From: Mark Crispin <[email-masked]>
Date: Tue, 31 May 1994 22:31:50 -0700 (PDT)

> case to use mail_fetchstructure() and mail_elt()?

The only disadvantage to doing this is in the case of multiple shared
read/write access to the mailbox; you won't get the flag updates.  However,
the very latest c-client/imapd does quite a bit towards making sure that flag
updates are communicated to the client in this case.

One general comment, though, is that doing all those mail_fetchstructure()
calls is likely to be much slower than the search.  As I told you before, it's
better to do a mail_fetchstructure() only when you actually have to display
it, since that is one of the most expensive functions in c-client.