On Fri, 10 May 2002 14:00:12 -0400, Pete Maclean wrote: > I totally, earnestly agree about creeping featurism. However I still yearn > for a clean way for IMAP to implement a move operation. (I mean "move" now > from the point of view of the user, not implying anything about a MOVE per > se in IMAP.)
The problem is that you are talking about implications. That is, you are implying that "move" is something other than a copy+delete. You run into trouble with other implications. Specifically, "move" also implies that it is possible to "move back". It isn't. Once a message has been removed from a mailbox it can never be placed back. The most that you can do is append a new copy of that message. You could simulate "move back" using copy+delete, as long as you never expunge... :-) Yes, this is the tired old "slippery slope" argument. But that old dog still fetches. I might also mention that I've been aware of the MOVE problem years earlier than anybody else. As a client author, I wanted MOVE on the server, since that is one of the first user interface functionalities that I implemented. But as soon as I got into the details, it became clear to me that it was better to do MOVE on the client. > 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. :-(
