On Fri, 10 May 2002, Rick Block wrote: >I almost always agree with Mark Crispin's comments posted >to this list (as should we all). However, I think adding >"move" would be a good thing since many (most?) clients >offer both "move" and "copy" options to the user. Some >servers could more efficiently implement move. I'm working >on a server for which I'd like to block move but not >copy to certain mailboxes. Forcing clients to implement >move using copy means I can't do this. >>Simpler is better. >Matching user interface actions to protocol actions is also good.
I agree on this, but the protocol should only provide the atoms, and the GUI should combine them to satisfy the needs of the end user. If the protocol implements every little fine detail of GUI hacking, we'll end up with a whole bunch of broken IMAP servers. Heck, the protocol is hard enough to implement already. It has all the atoms we need. But here's an analogy: The operating system provides system calls that let us "move" files, that is, in most cases the file is renamed. The end user goes "mv a b", and the file is moved, from the user's point of view. But the program "mv" doesn't actually move a file if it's across different file systems or partitions. It copies the file, and deletes the original. Should the operating system provide system calls for "moving" files also across file systems, just because we like to use the command "mv"? Compare the program "mv" to the GUI that lets a user drag one message and drop it over to another folder. And compare the operating system to the IMAP protocol. The protocol gives you all the atoms you need, both COPY, STORE, and, eventually, EXPUNGE (or UID EXPUNGE). COPY can be efficient if the storage unit it smartly designed. My implementation uses "link" if it's possible (and it always is). _Why_ do we need a MOVE command, when all is provided for? Is it for the end user? the programmer? for efficiency? I've never seen any problems with only using the COPY and STORE commands from the client- or server side. On the contrary, it helped me design a clean server and clean client MOVE operation. And I never ever heard any IMAP user complain about stray deleted messages. Andy >Rick Block >Avaya Inc. > >Mark Crispin wrote: >> Oh, so now you want a single-message expunge. I bet that it won't be long >> before someone gets the idea that they want an atomic command to do this too. >> >> What about the interaction with disk quotas? >> >> Folks, creeping featurism is not a good thing. It is especially not a good >> thing when the end user function is already possible with the existing >> functionality set, and the proposed new feature is a minor tweak that may be >> more efficient on some servers. > -- Andreas Aardal Hanssen
