Hi, Since move can be implemented by copy/store/store/expunge/store, we don't really need a move command. While being able to do the same thing with a single command would be convenient, you only save a few RTTs and some possibly some unsolicited data.
Now back to my "Trash"y thread... On Fri, 10 May 2002 08:57:02 -0700 (PDT), Mark Crispin <[EMAIL PROTECTED]> wrote... > I must stress, once again, that there is a difference between what a GUI > presents to the user and what actually occurs with the data. > > The problem is when people insist that what is done with the data must be the > same as what is shown to the user. It's wrong-headed and completely > unnecessary. In a ridiculous extrapolation of your assertion that a client should not change the data to mirror its GUI, I could assert that an IMAP server should only have a single mailbox and that other user mailboxes are just part of the client UI. Sometimes the actions done in the UI need to be reflected in the data. The trick is determining where and when to draw the line. > It is wrong-headed because it not only abuses the internal mechanism, it also > creates interoperability problems with other applications. Every time some > program unilaterally changes data so that the data mirrors its GUI, it imposes > that change upon every other program which uses that data. The result is a > mess. > > It is completely unnecessary, since it is completely possible for a GUI to > present the trash interface to the user without using a trash mailbox. It is possible to present your idea of a trash interface to the user without using a trash mailbox. My question is it possible to present my idea of a trash interface to the user with out using a trash mailbox? Here are the requirements I have been given... The "Trash" appears in the list of other mailboxes so it appears to be one of the user's ordinary mailboxes. Messages that have been deleted are to be found in the "Trash" (the name GUI is language dependent). That is any message deleted at any time by this client is to found in the "Trash". Not just this session, not just the deleted messages from the mailboxes that the client currently has open, but every single message deleted by this client that hasn't yet been permanently expunged. Messages that have been deleted are to be held for a user specified time before they are finally expunged and gone forever. The options for automatic expunging are never, at start up, at shut down or after being in the "Trash" more than 1 day, 1 week, 2 weeks, 1 month, or 3 months. Now, I realize that I'm not Albert Einstien; but, it appears to me that the simplest way for the client to meet its requirements is for it to append the messages which are to be deleted to a mailbox named "Trash". It then at the appointed time deletes and expunges messages from the Trash which can be never. Since append usually sets the internal date of the message to the current time, the client can determine how long the message has been deleted (in the "Trash") and automatically expunge it when necessary. IMAP provides all of the functionality necessary for my client to meet its requirements. I believe I have used the protocol as efficiently as possible to meet those requirements. In what way is my client "bad"? If there were a simpler and more efficient way of meeting my requirments, I'd really like to know what that way is. Please consider that the requirements for my trash interface cannot be changed. Regards, Mark Keasling <[EMAIL PROTECTED]>
