Re: Communciator 4.02 Imap EXPUNGE problem

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

We're starting to get closer to agreement.  :-)

On Tue, 26 Aug 97 08:39:47 -0700 Mark Crispin <[e-mail]> 
wrote:
> However, RFC 2060 doesn't quite state that as strongly as you suggest.

OK; I accept that.  I think, though, that most implementers *think of* IMAP 
as a protocol that allows simultaneous access to the same mailbox, and that 
it would be useful to state explicitly that some servers, under some 
conditions, do not, and that a client should not assume such capability.

> The bottom line is that there is an official documented mechanism to have
> multiple operations in progress on the mailbox, and that mechanism should be
> used.  Kludges just get you into trouble.

I most certainly agree with this.

> This suggests to me that you do not understand the data model behind IMAP;

No, I do understand it, but I contend that it's muddy.  First, the spec 
specifically refers to some things as "required responses".  Second, some 
responses (such as those to SEARCH) are very clearly attached to the 
commands that generated them.  Third, the lack of tags on the responses 
makes other things (like the indication that a message has gone away) more
difficult than it should be.  But never mind; this isn't central to the 
point at hand.

> > Perhaps we should add a CAPABILITY token for this -- some token that the
> > server returns in the CAPABILITY response that indicates its support for
> > multiple concurrent commands in the same session.
> 
> My contention is that a client that wants to use this facility should always
> use it, unconditionally.  This will work with either type of server.

Fair enough in the case we're talking about, but there are other cases when 
a client will want to know.  For instance, maybe I want to do a "FETCH 
1:50 ALL" to populate the screen, wait for the response, and then "FETCH 
51:* ALL" to let the rest of the data come through in the background.  But 
I still want to be able to get a "FETCH 5 BODY[1]" through if the user 
wants to read an item.  If I know that the server supports the parallelism, 
I can do that.  If not, I can't do it safely.  What you're saying (and I 
understand why) is that all clients have to be coded to assume that the 
server doesn't support this.  What I'm saying is that that means that in 
some cases I can't do certain optimizing that I might want to do.

> > A *message* can disappear, but a sequence number can't.
> 
> Not true.  If you expunge 100 messages from a 150 message mailbox, then
> sequence numbers 51:150 are history.

Only after the EXPUNGE responses come back.  But if I send a FETCH before 
then, the message numbers are still valid, and if I'm fetching data for a 
message that hasn't been expunged (which will be the case here if the UI is 
reasonably), its old message number is fine.

> I'd be rather disappointed in a database back end that had a slow EXPUNGE!
> That would lose 95% of the advantage of a database back end.

I can't agree with this: expunging hundreds of messages may take a 
significant amount of time, no matter what method you use for it -- even if 
for no other reason than that the server has to build and send all the 
EXPUNGE responses, in addition to whatever work is involved with 
invalidating the database records.

> I guess the problem I have with this is that it states the obvious!

Yes, and I think it doesn't; I think it's not obvious until we have a 
discussion like this.  Remember that you've been doing this for a long time 
and you have more than one implementation behind you.  Someone getting into 
this for the first time will reasonably assume that she can do these sorts 
of things, unless we say otherwise and point out why not.

> It certainly does not belong in the specification, which is large and 

Oh, absolutely.  I'm suggesting an "Implementer's Guide".  Perhaps I'll try 
putting together a draft of one, and let people beat on it and add their 
favourite stumbles.  I think such a document will be useful -- because if 
this stuff were really all as obvious as you say, not so many people would 
be stumbling over it.

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