Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2007-08-08 19:56:26
Size: 255
Editor: TimoSirainen
Comment:
Revision 3 as of 2009-06-02 17:05:32
Size: 3453
Editor: TimoSirainen
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
FIXME: Talk about \Deleted + EXPUNGE model, client-side Trash mailbox and its problems (quota, undelete and just plain annoying), server-side Trash (move-on-EXPUNGE by Courier, virtual Trash from all messages marked as \Deleted) The standard IMAP model for deleting messages is to first mark them with \Deleted flag and later issue EXPUNGE command, which deletes all the messages in the mailbox marked with the \Deleted flag. There are three commonly used models what IMAP clients do when a user hits "delete" key:

 1. Marks the message with \Deleted flag and changes the UI to use strikethrough for the message's entry in the message list. To permanently delete the message user has to issue EXPUNGE command using some button/key.
  * Advantages: Deleting messages is quick and easy, but since it still requires two steps deleting a message can't happen accidentally.
  * Disadvantages: Since the messages marked with \Deleted are visible, user wants to issue EXPUNGE almost immediately to avoid seeing them. Later if user comes to regret the deletion there's no way to undelete a message.
 1. Marks the message with \Deleted flag and hides the message from UI. There's also a way to toggle showing/hiding the \Deleted messages. To permanently delete the message user has to issue EXPUNGE command using some button/key.
  * Advantages: Same as with 1. Also user doesn't feel pressured to issue EXPUNGE immediately, since the messages aren't visible and distracting.
  * Disadvantages: The message gets hidden immediately when delete-button is clicked. If a user hits the button accidentally while not really paying attention to screen, there's no visible indication that it happened. User also may not realize that the messages still exist and that EXPUNGE would have be to be used once in a while to really get rid of them.
 1. Copies the message to Trash mailbox and marks it with \Deleted flag. The UI is changed with either 1. or 2. way. To permanently delete the message user has to issue EXPUNGE command using some button/key AND click an "empty trash" button.
  * Advantages: Some users may be more familiar with this model, since it's the same as how files are deleted in Windows, OS X, etc. Deleted messages aren't visible normally, but they can be recovered from Trash mailbox.
  * Disadvantages: To delete a message permanently requires more work. When undeleting the original mailbox information gets lost and user has to explicitly specify what mailbox to copy the message to. Problematic when user is over quota and tries to delete a message: the message copying will fail with "Out of quota" error.

1 and 2 could perhaps be improved by having a key to hide all current existing \Deleted messages, without hiding future deletions. This could maybe be also done automatically for messages deleted some hours ago. Also perhaps some indication of how many messages are marked \Deleted.

Another possibility would be to have a virtual Trash mailbox containing all messages that are marked with \Deleted. This would basically be 3. but without having to actually copy the message. Undeletion can be done by just removing the \Deleted flag. This virtual Trash could be implemented by either client or server. Server-side virtual Trash of course requires that the server is capable of that (few are) and that administrator has configured it. Client-side virtual Trash's main problem is how to make sure it contains all \Deleted messages, especially if user uses multiple clients. Unless the client synchronizes all the mailboxes all the time, the only practical way to implement it is to update the Trash only for opened mailboxes.

Deleting Messages

The standard IMAP model for deleting messages is to first mark them with \Deleted flag and later issue EXPUNGE command, which deletes all the messages in the mailbox marked with the \Deleted flag. There are three commonly used models what IMAP clients do when a user hits "delete" key:

  1. Marks the message with \Deleted flag and changes the UI to use strikethrough for the message's entry in the message list. To permanently delete the message user has to issue EXPUNGE command using some button/key.
    • Advantages: Deleting messages is quick and easy, but since it still requires two steps deleting a message can't happen accidentally.
    • Disadvantages: Since the messages marked with \Deleted are visible, user wants to issue EXPUNGE almost immediately to avoid seeing them. Later if user comes to regret the deletion there's no way to undelete a message.
  2. Marks the message with \Deleted flag and hides the message from UI. There's also a way to toggle showing/hiding the \Deleted messages. To permanently delete the message user has to issue EXPUNGE command using some button/key.
    • Advantages: Same as with 1. Also user doesn't feel pressured to issue EXPUNGE immediately, since the messages aren't visible and distracting.
    • Disadvantages: The message gets hidden immediately when delete-button is clicked. If a user hits the button accidentally while not really paying attention to screen, there's no visible indication that it happened. User also may not realize that the messages still exist and that EXPUNGE would have be to be used once in a while to really get rid of them.
  3. Copies the message to Trash mailbox and marks it with \Deleted flag. The UI is changed with either 1. or 2. way. To permanently delete the message user has to issue EXPUNGE command using some button/key AND click an "empty trash" button.
    • Advantages: Some users may be more familiar with this model, since it's the same as how files are deleted in Windows, OS X, etc. Deleted messages aren't visible normally, but they can be recovered from Trash mailbox.
    • Disadvantages: To delete a message permanently requires more work. When undeleting the original mailbox information gets lost and user has to explicitly specify what mailbox to copy the message to. Problematic when user is over quota and tries to delete a message: the message copying will fail with "Out of quota" error.

1 and 2 could perhaps be improved by having a key to hide all current existing \Deleted messages, without hiding future deletions. This could maybe be also done automatically for messages deleted some hours ago. Also perhaps some indication of how many messages are marked \Deleted.

Another possibility would be to have a virtual Trash mailbox containing all messages that are marked with \Deleted. This would basically be 3. but without having to actually copy the message. Undeletion can be done by just removing the \Deleted flag. This virtual Trash could be implemented by either client or server. Server-side virtual Trash of course requires that the server is capable of that (few are) and that administrator has configured it. Client-side virtual Trash's main problem is how to make sure it contains all \Deleted messages, especially if user uses multiple clients. Unless the client synchronizes all the mailboxes all the time, the only practical way to implement it is to update the Trash only for opened mailboxes.

None: ClientImplementation/Delete (last edited 2009-06-02 17:05:32 by TimoSirainen)