On Tue, 30 Jan 2001, Greg Noel wrote:
> I'm sorry, am I writing in Urdu or somthing?
Sometimes I almost think so :-)
> I clearly said it wasn't worth it
Sorry, I misunderstood you (although I still think you misunderstood me
and I was speaking about the option you did want, but anyhow, it doesn't
> It's a trade-off. I would opt to do it in advance (in a non-const function)
> with the potential of an occasional extra rebuild. (I would also opt for an
> incremental rebuild to minimize the penalty.) You would opt for a complete
> rebuild at every opportunity.
No, this is false. I do want to only modify the listing and not rebuild
it, it's just that I don't know how to do it right now - so I'm postponing
it for later time. You know, there are only 24 hours each day and I spend
2-3 during the last week on Mahogany - way more than I can afford.
> It's still unneeded. Why should I have to refetch a mailbox full of headers
> (potentially thousands of them) every time a single new message is added? I
> only have a ten megabit connection, after all...
You shouldn't, sure. But this is not the most urgent thing to fix -
getting rid of crashes and inconcistencies is a higher priority. I do plan
to alter listing rebuilding later.
> Uh, the documentation (remember that? You were just chiding me to read it?)
> specifically says that mm_exists() is how new messages are announced. If
> mm_exists() doesn't invalidate the header if the count is correct, we have
> saved a rebuild (which we already do too often).
I don't understand it. The problem I think about it this:
1. you have 10 messages in folder
2. you delete 2 of them
6. IMAP server notices that 2 new messages arrived
7. mm_exists(10) is called
8. you don't rebuild the listing and it is totally wrong
This is easy to fix, however, by counting the number of expunged messages
and comparing the mm_exists() argument with listing->GetCount() - nExpunged
instead of just GetCount(). I just didn't have time to do it yet (are you
> There's a fine line here. You _MUST_ do something to tell the user that you
> are responding to the request; if you don't, your users will think it is
> unresponsive, even if the total time is less. On the other hand, absorbing
> multiple requests into a single update is a good thing. But not sending the
> requests at all bothers me; something significant could get lost.
I don't see how? I think that the GUI (or ASMailFolder) should also use
the busy cursor and/or modify the status bar to put a "Busy" string into
it, but this is not related to MailFolder.
> I can see a function that scans the event list and removes any events that
> match some criteria, so that at the end of a FolderUpdate event you could
> eliminate any pending duplicate events, but even that makes me nervous.
Me too. Much more so, in fact. The problem is that events can be
dispatched before you can eliminate the duplicates.
> OK, this bothers me, too. Unless you check this absolutely everywhere, a
> maintanence nightmare of truly epic proportions, you can't be positive you
> haven't let something slip through. And you can't prove a negative, so you
> can't prove that you've included all the checks you need.
There are relatively few cclient functions. And if you forget the check,
you will hit the assert in GetHeaders() and/or BuildListing() anyhow...
This is not ideal (I'm almost sure some checks are still missing right
now) but is the best I can think of.
Also, notice that the checks should not be necessary at all! This is
not supposed to happen, after all.