On Thu, Oct 30, 2003 at 11:07:16AM -0800, Mark Crispin wrote: > Many clients wish to present a "trashcan" type graphical model, and expect > the server to implement that model by means of a "Trash" or "Deleted > Items" mailbox. That is, instead of treating the "trashcan" as a client > based graphical concept that maps to deleted messages, these clients want > the server to do the "move to trash"/"restore from trash" operations as > operations between the selected mailbox and the trash mailbox.
Too bad there's no usable way to create a trashcan-view without constantly looking into every mailbox to find the deleted messages. Also if server lacks UIDPLUS extension, it's not possible to expunge only part of the messages in trashcan. 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 That'd have the advantage of actually keeping the deleted messages for a while without being constantly reminded about them. Undeleting would be easy too. 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. > I've also noted a recent message talking about how IMAP is too "server > oriented." Such comments, and claims that I only think about servers and > never about clients, bewilder me. I have been both a client and a server > author from the start of IMAP. The first IMAP client and server were > designed in tandem, and the division of responsibility was based upon a > complete view of both. I think it's mostly that so many things are left unspecified and client implementors have to guess what of all possible things server might do. Many will just check a few server implementations and assume others work in similiar way. For example duplicates or non-hierarchy-level-ordered mailbox lists with LIST and LSUB. Or how exactly to deal with server namespaces (I'm not really sure either). 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). There's quite a lot of things that client authors are just supposed to know somehow. Client authors usually assume that servers always work in predictable ways. Server implementors have to deal with handling all kinds of errors and working environments that may not be obvious to client authors. So yes, once you have implemented an IMAP server you're usually quite capable of implementing a quite well working IMAP client. 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. > In many ways, the benefits of ENVELOPE have been overtaken by events; the > state of RFC 2822 parsers (and generators!!!) is much better, and many > programs need data from headers that is not in the ENVELOPE. But I think > that there is still some use for ENVELOPE. 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. > BODYSTRUCTURE is another matter. Clients which don't use BODYSTRUCTURE > and BODY[...] waste bandwidth, particularly with large MIMEgrams. I think BODYSTRUCTURE is a bit bloaty too and doesn't give enough information to clients which want more than what it provides. FETCH BODY.PEEK[*.HEADER.FIELDS (...)] would be a nice addition.
