Hi, On 2002.05.10 04:26 Mark Keasling wrote: > On Thu, 9 May 2002 11:15:42 -0700 (PDT), Mark Crispin > <[EMAIL PROTECTED]> wrote... >> You are better off using the natural native IMAP delete-expunge model >> internally, and make "trash" be a user interface concept rather than >> what happens internally. That is what all good client programs do. >> Only very badly designed and written clients actually create a >> mailbox called "trash" and copy messages to it. > > Mark, I haven't had my morning coffee yet so I'm still an incoherent > ogre. > > I'd very much like to agree with your assertion that the natural native > IMAP delete-expunge model (NNIDEM) is totally sufficient and write a > good client program. However, the NNIDEM does not meet my superior's > expectations and requirements as it only provides the Trash for the > currently selected folder and not the Trash for all of the folders on > the server.
My *personal* point of view is that IMAP is Internet Message Access Protocol, not an Easy Superior's Satisfaction Protocol. IMAP provides you with a flexible set of command allowing you to manipulate remote mailboxes, without adding any user interface paradigm on top of it. This keeps options open for those who do not want to have trash folder, and for those who do. > My boss unlike some people does not like having deleted messages > interspersed with his other mail. He wants it to go away as soon as > its deleted. Once my boss has deleted a message, he expects to find > it in the "Trash" folder without having to remember which folder it > was in previously and selecting that folder to get at its trash. This > is the inevitable result of providing a "Trash" folder virtual or > otherwise. Nothing's stops you from implementing this within Internet Message Access Protocol. You can always hide in your client messages marked as deleted, and copy them to Trash folder, if you find it attractive. > The other expectation is that the Trash can be allowed "decompose" so > that once a messsage is been deleted and placed in the trash, it can be > safely forgotten as it will be expunged after a configurable amount of > time or it matches some user or system administrator defined > criteria. Using the NNIDEM, > the client has no standard way to determine when the deleted flag was > set and so can not automatically determine if the deleted message > should be expunged after a certain amount of time (1 day, 1 week, 1 > month...). You can always add a X-Deleted-On: header. 2. I, for one, would not like administrators mess with mail e-mail, no matter if I marked it deleted or not. > The main reason for administered Trash is that once a message is in the > Trash it is usually forgotten and the Trash becomes a diskfill. This > occurs regardless of whether the deleted messages remain in original > folder or have been moved to a Trash folder. Some mail clients have an "expunge on exit" option. This is not a protocol problem, it is client implementation problem. > While automatically expunging deleted messages is not exactly a nice > thing to do; it is a capability that apparently system administrators > want. 1. Which system administrators? 2. What exactly stops you from using EXPUNGE on all the folders? > My arguments that IMAP has a nice NNIDEM that should be used instead > of a Trash folder have gone unheeded. Having deleted messages moved > to a real Trash > folder provides system administrators with a single point of access > when the disk on the mail server goes critical. Most users don't > complain if the Trash unexpectedly disappears; however, would complain > if all of the deleted messages in all of their folders were to > disappear. What is the difference between deleted messages in Trash and deleted messages in other folders? I am not sure if I understand... Regards, Pawel > Your insistence that NNIDEM is good and everything else is bad is > beginning to sound like you are trying to purvey something that even > though it has great technical merit still doesn't sell. > > Regards, > Mark Keasling <[EMAIL PROTECTED]> > > -- > ----------------------------------------------------------------- > For information about this mailing list, and its archives, see: > http://www.washington.edu/imap/imap-list.html > ----------------------------------------------------------------- >
