mailing list archives

Continuing with my newly implemented extensions:

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. So I went and
finally implemented support for running multiple commands in parallel,
and added a new command:

X-CANCEL <tag>

If a running command is found with the given tag, X-CANCEL replies
immediately with OK and causes the running command to stop at the next
possible moment, possibly truncating its output. So for example a FETCH
command would stop after it has sent the current untagged FETCH reply,
and a SEARCH command might send a partial untagged SEARCH reply. The
cancelled command will then reply with "NO Command cancelled.".

If a running command wasn't found with given tag, X-CANCEL replies with
NO.

Comments?

BTW. Has anyone implemented the parallel running of commands before? So
that two FETCH commands could send replies mixed together? I'm just
wondering if there are clients that are going to break.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20061220/746cc3e1/attachment.sig>

Timo Sirainen writes:
> X-CANCEL <tag>
> ...
> Comments?

None now - I'm really in pack-and-leave mode.

> BTW. Has anyone implemented the parallel running of commands before? 
> So that two FETCH commands could send replies mixed together?

Yes.

> I'm just wondering if there are clients that are going to break.

Some mutt breakage was the worst I've seen, and the mutt developers 
fixed it quickly when I reported it. There's breakage in 1.5.x, where x 
is 12 and a little smaller. Generally the clients that send multiple 
commands handle the responses.

STORE+STORE and STATUS+STATUS are common. I posted a longer list a month 
or two ago. Can't remember more now.

Arnt

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.

Arnt Gulbrandsen writes:
> Timo Sirainen writes:
>> BTW. Has anyone implemented the parallel running of commands before? 
>> So that two FETCH commands could send replies mixed together?
>
> Yes.

Some Christmas fun for you:

a select mailbox1
b fetch * uid
c select mailbox2
d fetch * uid

I didn't care much about that sequence - it's both invalid and AFAICT unused.

a seach body a
b logout
c noop

You must execute those in order: Either a, b or a, b, c (NOOP is in 
command-any, and command-any is valid after LOGOUT). I like this one ;)

Arnt

On Wed, 2006-12-20 at 14:12 -0800, Mark Crispin wrote:
> 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?

Actually the search itself isn't really the problem here, it's the text
search index building which is much slower than the search. 

Because most users don't use SEARCH in all of their mailboxes (if any),
I'm delaying the initial building until the user does SEARCH for the
first time. If the mailbox is large, it's going to take time. With my
computer it's currently indexing only 1,5MB/s (CPU limited).

I did think about simply doing a normal search first, and then start
building the indexes on the background so the future searches will be
fast. Maybe I'll do that also later.

(I'm here talking about an indexer that supports substring searches so
it'll work with standard TEXT and BODY searches)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20061222/eeb18b29/attachment.sig>

On Fri, 22 Dec 2006, Timo Sirainen wrote:
> I did think about simply doing a normal search first, and then start
> building the indexes on the background so the future searches will be
> fast. Maybe I'll do that also later.

That sounds like an excellent idea.  Any advanced IMAP implementation will 
try to anticipate what it will be called upon to do next, and prepare 
itself.  Doing this stuff in the background and/or piggybacked on other 
stuff (such as a client doing anticipatory aggregate FETCHing to avoid an 
RTT later) saves a lot of time.

Good luck!

-- Mark --

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