Re: Communciator 4.02 Imap EXPUNGE problem

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

On Tue, 26 Aug 97 11:28:45 -0700 Mark Crispin <[e-mail]> 
wrote:
> predictably.  It is an unwarranted assumption that the server will 
> recognize that the "FETCH 5 BODY[1]" is more important than a "FETCH 50:* 
> ALL"!  In fact, one can come up with scenarios in which it may be the other 
> way around (maybe the ALL fetch is more urgent to finish quickly than that 
> 50GB video clip...)!!!!

Yes, good point.

> *Begin flame*
> It gets awfully frustrating when I make a recommendation, and immediately
> someone goes and contradicts me and/or says that it's due to a "stealth" bug
> in my implementation.
> *End flame*

Understood.  I think I speak for most people here in saying that I *do* 
value your recommendations; if I didn't, I would just write you off as a 
kook and wouldn't waste time discussing it.  And in case you've 
misunderstood me in this, I'll say once more that I am *not* blasting your 
implementation, but simply saying that I can understand (being there 
myself) how it's very easy to make what looks like a reasonable 
implementation decision and then to later find out that it operates badly 
with your (or some other) server.  The more of this we can document, the 
better for future implementers.

> But, what happens what you say something in your "implementor's guide" that
> you feel strongly about, and I feel equally strongly that it's 
> completely different, and Chris Newman feels equally strongly that the 
> right thing is completely different from what either you or I thinK?
> 
> Most of this document will inevitably be religion.

No doubt some of it will.  I'm hoping, though, that more of it will be 
along the line of
* beware of making this assumption; some servers do not support it,
* beware of doing this or that with the protocol; in some configurations 
  it's dangerous,
* be sure to consider this or that, because we've seen problems with it.

Items that come to mind are warnings against using <LIST "" *>, warnings 
against doing anything (such as multiple SELECTs or STATUS) that will cause 
one mailbox to be active more than once, warnings about the usability 
issues involved in failing to deal with subscriptions, warnings about 
assuming that you can create a mailbox with any particular name, and so on. 
I don't want to say what one *should* do -- only what has caused problems 
with implementations so far, so that others can take that into account when 
they implement.  And then if they choose to ignore the warnings, at least 
they do it with an understanding of the issues.

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