1 IMAP enhancements, by priority:
5 * Smarter connection code. Mutt should handle dropped connections/routing
6 problems gracefully. It should be able to transparently reconnect. This
7 is facilitated by the next item.
11 * General connection code rewrite. All commands should be queued via
12 a single interface for communicating with the server. Nothing should
13 have to read or write directly to the socket.
19 * We should maybe add a new imap_format string for IMAP browsing, without all
20 the stat variables but with tags like how many messages are in the folders,
21 how many subfolders, that weird \Marked tag, etc.
27 * Persistent caching of data. I think the nicest way to do this is to store
28 local copies like IMAP does, with an invisible control message at the top,
29 and extra invisible headers in the message (for UID/dirty bits). This does
31 o We can use the existing mbox driver.
32 o Mutt can read mail stored in IMAP spools transparently and
34 o An IMAP server could function off of a local cache - maybe we can begin
35 to develop some sort of IMAP clustering system.
37 o IMAP can't discriminate between its own store and a fake Mutt cache. If
38 the server changes its file format, bad things might happen. Could be
39 worked around with a specific Mutt header in all messages, probably.
43 * Instead of testing for the existence of a mailbox for APPEND, just append
44 and create/retry on failure. This is only a small bandwidth savings, but
49 [ -- new features -- ]
51 * Commands for creating/deleting folders on the server, since users may not
52 otherwise be able to do this on IMAP servers.
53 Delete done, still must implement create.
57 * Implement the x (quit without saving changes) command.
61 Brendan Cully <brendan@kublai.com>