Subject: Expunge Nightmares (was Re: More on /SEEN and /DELETED...)

From: Adam Treister <[email-masked]>
Date: Wed, 20 Oct 93 16:30:11 -0800

>   Instead of thinking of message n as ``message number
>   n'', think of it as being ``the nth extant message''.

Doesn't this imply order and contiguity?  Mailstrom contains views that are a
subset of a folder, and not necessarily in the same order as the server stores
them.

The current version of Mailstrom treats the address of the Message Object as
the
"primary key", so I won't have to remap, but whenever I get an expunge message,
I'll have to still do a lot of list traversals to determine which of my views
contain the message.

Now that I look at, I may indeed have to change every views instance of every
object!

As I read the c-client, imap_expunged is called when an unsolicited * EXPUNGE
12
arrives.  It frees up its element's memory and then calls mail_expunged, which
further destroys the element, clears its msgno and recycles the element.
expunged then calls mm_expunged sending my app the fact that msgno 12 is now
gone.

Mailstrom's Message object doesn't store the msgno; it stores the MESSAGECACHE
*element, and asks c-client for msgno via the element.  I guess I could
recognize the element that used to belong to 12, cuz it'll now have a msgno of
0, but it'd be nicer if I got called before the element gets wiped.

I'm trying to avoid storing the 12 in my Message object, because that would
necessitate changing all instances > 12.

Can I store my Message in the element so mm_expunged can call:

element->messageObj->Remove();

What is the rationale for remapping all msgno's on every expunge?  Sure it
makes
for some easy lookup, but it would be easier to use a hash table to find row
number from message number, than to change every reference to message number in
every table, message, and reply.  Any chance we could get message numbers to
stay static for the life of the connection, or even the message.

Adam

---

From: Mark Crispin <[email-masked]>
Date: Wed, 20 Oct 1993 16:37:04 -0700 (PDT)

I sent a message to Adam on this, but briefly, the solution to Adam's problem
is to use elt locking.  An elt has a lock count, which is decremented each
time mail_free_elt() is called.  Only elt's whose lock count (or share count
if you prefer) has reached zero are actually freed.

An elt whose msgno element is set to 0 is one that has been expunged and no
longer refers to an extant message.  The msgno of an elt is always current
with the latest expunge status.  That is why elt's have a msgno element.

In other words, the mechanism that Adam asks for is already there.