todo

mutt-1.5.12 源代码。linux 下邮件接受的工具。

IMAP enhancements, by priority:

[ -- socket -- ]

* Smarter connection code. Mutt should handle dropped connections/routing
  problems gracefully. It should be able to transparently reconnect. This
  is facilitated by the next item.

  PRIORITY: [***]

* General connection code rewrite. All commands should be queued via
  a single interface for communicating with the server. Nothing should
  have to read or write directly to the socket.

  PRIORITY: [***]

* Interruptible socket calls, preferably without having to abort the
  connection. For example large downloads could be chunked.

[ -- browsing -- ]

* We should maybe add a new imap_format string for IMAP browsing, without all
  the stat variables but with tags like how many messages are in the folders,
  how many subfolders, that weird \Marked tag, etc.
 
* Namespace handling needs to be thrown out and rewritten

[ -- speed -- ]

* Partial index loading, using server-side threading and sorting

* Partial message loading, including parsing BODYSTRUCTURE for the
  view-attachments menu

* Persistent caching of data. I think the nicest way to do this is to store
  local copies like IMAP does, with an invisible control message at the top,
  and extra invisible headers in the message (for UID/dirty bits). This does
  some nice things:
  o We can use the existing mbox driver.
  o Mutt can read mail stored in IMAP spools transparently and
    nondestructively.
  o An IMAP server could function off of a local cache - maybe we can begin
    to develop some sort of IMAP clustering system.
  Disadvantage:
  o IMAP can't discriminate between its own store and a fake Mutt cache. If
    the server changes its file format, bad things might happen. Could be
    worked around with a specific Mutt header in all messages, probably.

* More aggressive command pipelining

[ -- new mail detection -- ]

* Possibly opening multiple connections for mailbox polling, now that
  we have IDLE support.

* using UIDNEXT/UIDVALIDITY to find new messages instead of relying on
  the ephemeral RECENT tag or the unchanging UNSEEN one. If we could
  cache it between sessions we might have a nice way to properly
  handle OLD messages too (UID less than cached UIDNEXT, but still
  UNSEEN).

Brendan Cully <[e-mail]>
Updated: 20051212