Re: Communciator 4.02 Imap EXPUNGE problem

["Barry Leiba, Multimedia Messaging" <[e-mail]>]

On Sun, 24 Aug 97 09:52:15 -0700 Mark Crispin <[e-mail]> 
wrote:
> I am very hard-pressed to think of any circumstance with any server in which
> the client receives any benefit by opening multiple sessions to the 
> same mailbox on the same server -- not even when the mailbox format permits 

Well, I can think of one or two - note that I'm not condoning it here, just 
offering reasons why a client-writer might think to do it.  Because there's 
no way for the client to know whether the server will or will not support 
multiple commands running simultaneously, and because some commands (such 
as EXPUNGE, or especially COPY and SEARCH) may take a significant amount of 
time to run, the client-writer, who would like to simply send the one 
command and allow a subsequent FETCH to run at the same time, is probably 
trying to guarantee that effect by doing the possibly-long-running command 
in another session.

This clearly is a loser on an EXPUNGE of only a few messages, or a quick 
SEARCH or COPY (where the overhead of establishing another session 
outweighs the benefit), but with an EXPUNGE of hundreds of messages, for 
instance, or a long-running SEARCH, it can, indeed, improve the performance 
for the interactive session by not making it wait for the EXPUNGE or SEARCH 
to finish.  Of course, it's done with the understanding that it can't tell 
whether an in-progress SEARCH will or will not allow a FETCH to run, and it 
doesn't take into account that it also can't tell whether the second 
session will interfere with the first in any significant way.  

Then, again, there is nothing in the RFC that indicates that one shouldn't 
do this.  I repeat, yet one more time, that tossing criticism around for 
someone's "doing such a bizarre thing", and accusing that client of "highly 
anti-social" behaviour, when the client-writer followed the spec is 
inappropriate.  Instead, let's use these experiences to clarify the spec or 
to add to an "implementer's guide" that warns people against doing things 
that commonly deployed servers or mail stores or whatever can't handle well.

Barry Leiba, Multimedia Messaging  ([e-mail])
http://www.research.ibm.com/people/l/leiba