Timo Sirainen wrote : > I would really like such user interface. With some help from server it > would be possible: > > - virtual trashcan mailbox in server-side which contains all \deleted > messages in all mailboxes > - server-side automatic (client-configurable) expunging of messages older > than n days. automatic expunging if quota is getting full. > - client wouldn't list \deleted messages > - a way to show \deleted messages and expunge them directly > - when deleting messages, it's not nice to immediately hide them. rather > client's expunge key should hide them, not expunge (well, maybe different > keys). > - undeleting message in trashcan automatically does the right thing > - client could support partially expunging mails from trashcan by using > UID EXPUNGE. In UI that'd be done with the normal delete-expunge way
these are some idea, I have to take some note. > Hmm. Maybe it'd work just as well without the virtual trashcan if everything > else was there :) Currently I'm just annoyed at seeing the deleted messages > there so I expunge them immediately (and sometimes wish I hadn't), but I'm > afraid to just hide the deleted messages since then I'd never remember to > expunge them. isn't there possibility to do some automatic expunge when selecting other mailboxes ? (CLOSE) > You always complain about some clients trying to select the same mailbox > using multiple connections. Is this even discouraged in RFC (it's not under > SELECT), or how would client authors know not to do it? I can think of a few > reasons why client might want to do that (long standing or background > operations in one, user interactive operations in another). Maybe the client should schedule the given operation between background operations are user interactive operations ? > We'd really need a IMAP client implementor's guide which talks about the > philosophy of IMAP (untagged commands, NO-reply, etc). Different server > working environments and what problems they have. What kind of replies > server might give to commands and why. Why server might fail in certain > situations and how client should behave in such situations. Best practices > to implement several UI features (UI itself and how to do it with IMAP). > etc. It'd be quite a long guide. Isn't there the ten commandments ? That could be a start. > I'm not saying we should depricate ENVELOPE, but I don't think it's fare to > consider clients not using it as behaving badly either, simply because > servers might have been more optimized to fetch ENVELOPEs. that's why I still use ENVELOPE for my client. -- DINH V. Hoa, "Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
