Re: Communciator 4.02 Imap EXPUNGE problem

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

On Mon, 25 Aug 97 12:11:34 -0700 Mark Crispin <[e-mail]> wrote:
> It exploits a weakness in operating systems whose scheduler allocates by
> process, instead of by user.  A client which spawns multiple server 
> processes (in *ANY* protocol -- this includes HTTP) seeks to grab a greater 
> share of the server's resources (and bandwidth to the server) to the 
> detriment of clients which do not.  It adds overhead to the server because 
> these additional server processes need to be scheduled.

I agree with you if we're talking about a client that spawns multiple 
processes to try to pump more work through the server (as many HTTP 
clients do).  In this case, though, we're not talking about that - we're 
talking about the idea of a client's managing *two* (not "a bunch of") 
server processes: one to which it sends work that it thinks might be 
long-running and another to which it sends short-running work for which 
relatively prompt interactive response is desired.  The idea isn't to pump 
more work through the server, but to have one process that it knows will 
not be blocked by a long-running request.

> > 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.
> 
> This isn't IMAP-specific.  It is a fundamental software engineering 
> principle, the sort of thing that belongs in CS 101.

Such management as I describe above *is* a good thing in general, and 
would, in fact, be taught in a CS class as something that one *should* do 
(as I say, for specific reasons, and not with the aim of stuffing more of 
*my* work at the server, hoping to crowd out *your* work).  If it's a 
particularly bad idea in IMAP, owing to elements of server back-ends which 
may not be obvious to many implementers, then it's worth making note of it.

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