MBOX-Line: From MRC at CAC.Washington.EDU  Wed Dec 20 14:12:30 2006
To: imap-protocol@u.washington.edu
From: Mark Crispin <MRC@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] Command cancellation
In-Reply-To: <1166644158.22214.365.camel@hurina>
References: <1166644158.22214.365.camel@hurina>
Message-ID: <alpine.WNT.0.81.0612201323310.3064@Shimo-Tomobiki.panda.com>

On Wed, 20 Dec 2006, Timo Sirainen wrote:
> I wanted an ability to stop an ongoing SEARCH command, so that it'd be
> possible to add a "Cancel search" button in the client.

How long do searches take in your server?

Once messages are parsed, I've never had a search in my server fail to 
outrun anything like a CANCEL operation.  The only time I've seen a search 
of a large mailbox take a noticable amount of real time is when a large 
number of messages haven't been parsed for MIME structure yet.  That will 
be resolved in a forthcoming update to the mix format that caches 
envelopes and bodystructures.

Due to IMAP's stateful nature, in most cases the only choices are to wait 
or to abandon the session.  SEARCH, SORT, and THREAD are the only obvious 
commands that could benefit from CANCEL; and in all three cases it should 
be possible to resolve performance problems.

In general, I think that it's preferable to remedy performance problems 
rather than to create a complex mechanism (and the necessary semantics of 
CANCEL are complex) to work around performance problems.

With that in mind, CANCEL seems to me to be a solution in search of a 
problem.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

