On Fri, 16 Apr 2010 18:50:40 -0700 (PDT) Mark Crispin <mrc...@panda.com> wrote:
MC> On Fri, 16 Apr 2010, Vadim Zeitlin wrote: MC> > On Fri, 16 Apr 2010 08:25:41 -0700 (PDT) Mark Crispin <mrc...@panda.com> 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> MC> Why not create archive mailboxes for that purpose? Sorry, what's the difference? MC> Or, better yet; why not make a client that allows you to focus MC> specifically on the messages you want to see all the time, while ignoring MC> the other ones that you keep for 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). MC> What prevents the server management from blowing away a trash mailbox MC> automatically without your consent (e.g., "the disk is full, let's delete MC> everybody's trash")? 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. MC> Trash, or for that matter deleted status, is not a good archiving MC> mechanism. Again, maybe there is some special meaning of the word "trash" that I'm simply missing but I just don't understand the difference. For me "trash" is definitely the archiving mechanism. MC> > I'd be interested in hearing your thoughts about how could this UI be MC> > implemented in a better way from IMAP point of view. But personally I can't MC> > think of anything. MC> 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... MC> Most users really do not have dozens of mailboxes that have active status MC> that needs to be constantly checked for trash. 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". In fact I don't see at all what does it mean. I'm afraid you give the word "trash" some meaning which I am simply not aware of. MC> In fact, most users have an INBOX plus some archive mailboxes, and the MC> latter never have their contents deleted. So implementing Trash as a MC> client representation of \Deleted status isn't as crazy as it sounds. Well, yes, this might work but, as previously mentioned, I have several problems with it: 1. You should never ever call expunge or you lose your entire archive. This is a problem because sometimes you do want to expunge some message(s), e.g. because you got a spam (which you don't want to keep in archive) or because some poor misguided soul sent you a 50MB attachment which you don't want to keep in the mailbox forever neither. 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). 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. It also consumes extra 30MB or so of RAM because now the program needs to keep the threading information in memory (normally threading is disabled for trash so it doesn't bother to do it). Anyhow, 30MB is not much but I'm definitely not prepared to wait for a minute when opening a mailbox. Nor even for 10 seconds. 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. And what else is good about this approach? I guess one nice thing would be to be able to view all messages of this mailbox, deleted and not, which you've ever received. But while this could occasionally be useful it would only happen rarely and I don't see it compensating for the problems above especially because this could be implemented with a physical trash as well by providing a virtual view of the mailbox with the trash. Of course, this would work best if each mailbox had its own trash instead of using a common one for all of them. And while my client does allow you to configure the trash mailbox independently for each normal mailbox, this is where I think it could be improved: instead of using the global /Trash by default it should default to creating (a normally hidden from user) mailbox/.trash for each mailbox. And then the global trash could be implemented as a virtual view combining all of the .trashes. This would IMHO be really ideal. Is this closer to what you meant or did I completely misunderstand you? VZ
pgpwJ7v7PtgJ2.pgp
Description: PGP signature
_______________________________________________ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
