This message is a follow up to one that hit the list about a month ago
under a thread titled "Trash folders...". For reference, the relevant
material, consisting of a suggestion that I made and Mark's response, was:
> > Now I am going to stick my neck out, risk the wrath of the keepers of IMAP,
> > and suggest one other thing I want. This, I admit, smells a little more of
> > feature creep but it would make life very much more comfortable for many
> > users. I would like a feedback mechanism for the COPY command, so the
> > server sends an untagged response as each message in a set is copied.
>
>I referred to this in passing earlier.
>
>It was tried, and it was a huge loser.
>
>In order for it to be meaningful, you have to send a TCP push on those
>responses. Otherwise, they get buffered together, the client doesn't get the
>incremental updates, and then WHAM! along come all of these updates and the
>tagged OK. On the other hand, doing a TCP push per-message is also a big
>loser.
>
>I think that what you really want is not per-message updates; instead, I think
>that you want time-based updates. There's no point in spending getting a huge
>amount of update information if that significantly delays the "done"
>indication; that's what happened when COPY sent updates years and years ago; a
>silent COPY that took 3 seconds took over a minute with updates due to the
>overhead of the TCP Push.
>
>I will support an extension to IMAP that would cause the server to send
>command progress updates as untagged OK every N seconds for commands which
>take more than N seconds to execute. This would be particularly helpful with
>SEARCH, SORT, and THREAD, all of which are known to take potentially a long
>time. In fact, I have much of the internal infrastructure to do it in my
>server already, so (as long as it doesn't go off the deep end) I could have it
>available for client authors pretty quickly.
>
>The idea is not that you get "such-and-such message was copied", but rather
>something like "10283 out of 43924 messages copied".
>
>Unfortunately, going off the deep end has been a traditional problem with any
>proposed IMAP extension. :-(
I have given this matter a great deal of thought and now want to offer the
following:
First, Mark's response makes absolutely clear the wisdom of sending
progress messages on a periodic basis and the complete wrong-headedness of
issuing them on a per-operation basis.
I would like progress responses to be general in the sense that they could
be sent for any command at all. Obviously they would be most useful for
commands like COPY and SEARCH but, in pathological circumstances, I can
imagine any command taking a long time. I would particularly relish having
progress responses for LISTs and LSUBs since there is no way a client can
determine in advance how many mailboxes are going to be listed.
Here is a possible format for a progress response. My intention is
primarily to list the components of such a response; precise syntax can be
resolved later:
* PROGRESS <tag> <user-text> <progress-indicator> <time-to-go>
The <tag> identifies the command that the response pertains to. This is
necessary since multiple commands may be active simultaneously. The other
fields are all optional. Obviously enough, progress responses may be sent
only prior to the tagged response to the command in question.
The <user-text> is a string that the client may display to the user such as
"Processing message #45".
The <progress-indicator> is something that a client can interpret and
convert to something like a progress bar. It would have one of three
forms: "N/M" where N and M are integers (N<=M) meaning processing the Nth
of M whatevers (messages, mailboxes, etc.), "N%" meaning N percent done,
or, for exceptionally lengthy cases, "N%%" meaning N per mil done.
The <time-to-go> is a count of seconds that the server expects to be
occupied completing the command. This should be included only when the
server can make a good estimate of it.
So, a complete example, say for a COPY command, would be:
* PROGRESS 124 "Copying message #33" 12/40 8
Perhaps it would be wiser to include a unit specifier on the
<time-to-go>? So you could have, for example, "12s" meaning 12 seconds,
and likewise 'm' for minutes and 'f' for fortnights. (Oops, bad inside
joke there. Sorry!)
A server would not be required to include all components. In this syntax,
missing elements could be indicated by, say, dashes. Thus, to indicate
only the expected time to completion, a server could send:
* PROGRESS 124 - - 10
Alternatively, since each optional element could be identified by its
syntax, they could be sent in any order.
A progress response with no information except the command tag would be
useful in preventing client time-outs:
* PROGRESS 124
Servers would be encouraged to issue an initial progress response as soon
as possible after receiving a command iff that response can convey a count
of elements to be processed and/or a time-to-go, and the operation is
expected to take more than a few seconds.
It is important that a client must not take any progress response, even one
indicating 100% completion, as meaning that the command will actually
complete successfully.
I don't feel competent to select a syntax that fits best into the IMAP
mold. Perhaps something like the following would be preferable to my
suggestion above:
* OK [PROGRESS <tag> TTC <seconds>] <Message for display to user>
Where TTC means time to completion.
One other thing I am unsure about is the number of seconds between progress
responses. Should this be decided by the client? By the server? By
negotiation between the two? Or should it simply be a fixed number? My
inclination is that it be chosen by the server within some allowable range,
say 5 to 60.
Pete Maclean
--
-----------------------------------------------------------------
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------
