On Sat, 17 Apr 2010, Vadim Zeitlin wrote:
MC> > However I do like trash model for other MC> > mailboxes because it allows me to keep the deleted messages if I ever need MC> > them again. Think about trash as being "archive" in this case. MC> Why not create archive mailboxes for that purpose? Sorry, what's the difference?
By calling something Trash, you are inviting its destruction without notice to you. Trash. n. things that you throw away because you no longer want or need them. Archive. n. a collection of historical documents or records; the place where these records are stored. v. to put or store a document or other material in an archive.
Well, this seems like something that I thought about, i.e. use client-side filtering to exclude the deleted messages. But while this could work I don't really see what advantage would this provide while this clearly will have many problems (e.g. interoperability with the other clients which wouldn't hide the messages marked as "archived" in the mailbox).
Yet, in the name of "interoperability", you are storing archive data in a place where you have granted implicit permission for its destruction!
If you assume that the server management can delete your mailboxes without your consent, there is nothing I (or anybody else) can do to help.
Not just server management. ANYTHING. A trash can is not a file cabinet. You can not blame the janitor from emptying it while you are out of the office. But it's not just the janitor. It may be your co-worker (or, to make the metaphor clearer, it may be an application that, unknown to you, automatically empties trash).
MC> The main hangup that people have is the difficulty of visually displaying MC> a trashcan icon that covers multiple mailboxes without having all those MC> multiple mailboxes open. Do you mean users or developers by "people" here? In any case I don't think I ever heard anybody complaining about it...
That is the only excuse for implementing the client trash can visual metaphor as a mailbox called Trash. It is otherwise completely unnatural and inappropriate for the IMAP model.
What does it mean to "check for trash"? I personally do have dozens of mailboxes which use trash (and dozens more which do not) but I don't "check them".
You evidentally are a novice in this. I strongly suggest that you do some research before inflicting yet another bad client on the world. The issue that I refer to is whether or not to show the trash as being "empty" if there is no Trash mailbox, but instead simply \Deleted status on messages. If you fret about the possibility of a message being deleted in some mailbox that is not normally opened, and want that reflected in the Trash status, then you have to check that mailbox to see if it has deleted messages before showing the Trash status. The point that I am making is that for the vast majority of users this is a silly argument. But it is the only argument to justify a Trash mailbox, which in every other way is inferior to the IMAP delete-expunge model.
1. You should never ever call expunge or you lose your entire archive.
[a] Don't delete messages unless you are willing to have them vanish at any time without notice to you. [Don't throw things in your office trash can unless you are willing to have them vanish while you take a restroom break because the janitor came by at that time.] [b] Use a proper archive mechanism. [c] IMAP UIDPLUS-capable servers have UID EXPUNGE
2. Interoperability suffers. If you have to use another client you will see all the deleted messages in it. Worse, it might decide to expunge them, see (1).
Nothing whatsoever prevents the same fate from happening to a trash mailbox.
3. Performance will suffer as well. My "active" mailboxes have from a few hundred to a couple of thousands messages in them and this, of course, is not a problem at all. Having several dozens of thousands of messages might though. In fact if I open my trash right now, it takes 1 minute for the server (Dovecot 1.2) to thread it.
Panda IMAP is not that slow. It can thread 50,000 messages in under a second.
And mostly I just really don't see what are the _advantages_ of doing it. Of course, undeleting becomes easy/trivial, but this is a rare operation and with UIDPLUS support it's not difficult with the trash neither.
You can't put a message back if it has been moved of the mailbox. All you can do is create a new copy. I should also note that Gmail does exactly what I say should be done by IMAP clients. The problem with Gmail is that it forces it on the back end, then layers IMAP on top on that and does it wrong. In Gmail, everything is in one mailbox. Everything else is a view in that mailbox. This is exactly what IMAP keywords are good for, but instead Gmail kludges the IMAP mailbox interface for it (and there are problems because it isn't possible to get that completely right). A much better way to layer IMAP on top of a Gmail type store is a stubbing interface. I'm currently designing a new storage architecture that does just that. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Imap-uw mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
