123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990 |
- f{,data}sync() usage could be optimized by batching the calls.
- automatically resume upon transient errors, e.g. "connection reset by peer"
- or timeout after some data was already transmitted.
- possibly also try to handle Exchange's "glitches" somehow.
- uidvalidity lock timeout handling would be a good idea.
- should complain when multiple Channels match the same folders.
- should complain about nonsensical combinations like Sync Pull + Create Both.
- propagate folder deletions even when the folders are non-empty.
- - verify that "most" of the folders in the Channel are still there.
- - refuse to delete unpropagated messages when trashing on the remote side.
- - refuse to delete far side if it has unpropagated messages. symmetry?
- add option to suppress complaints about folders that would need creation
- (but not deleted ones).
- add message expiration based on arrival date (message date would be too
- unreliable). MaxAge; probably mutually exclusive to MaxMessages.
- add alternative treatments of expired messages. ExpiredMessageMode: Prune
- (delete messages like now), Keep (just don't sync) and Archive (move to
- separate folder - ArchiveSuffix, default .archive).
- add support for event notification callbacks.
- make it possible to have different mailbox names for far and near side in
- Patterns.
- - use far:near for the pattern
- - supporting names with colons requires and extension of the parser to
- report which parts of an argument were quoted
- - this makes Groups mostly useless, as they are mostly a workaround for this
- function being missing so far
- - this is needed for move detection, which would work only within one Channel
- - this supersedes MapInbox
- add regexp-based mailbox path rewriting to the drivers. user would provide
- expressions for both directions. every transformation would be immediately
- verified with the inverse transform. PathDelimiter and Flatten would become
- special cases of this.
- add daemon mode. primary goal: keep imap password in memory.
- also: idling mode.
- parallel fetching of multiple mailboxes.
- TLS session resumption becomes interesting then as well.
- imap_set_msg_flags() & imap_trash_msg(): group commands for efficiency.
- add streaming from fetching to storing.
- this is complicated by the IMAP target needing the final size in advance,
- which we can't know in a single pass when newline translation is necessary.
- handle custom flags (keywords).
- this is impeded by there being no Maildir-side standard.
- make use of IMAP CONDSTORE extension (rfc4551; CHANGEDSINCE FETCH Modifier);
- make use of IMAP QRESYNC extension (rfc5162) to avoid SEARCH to find vanished
- messages.
- make use of IMAP CAPABILITY APPENDLIMIT= extension (rfc7889; fastmail & gmail).
- this is really useful only for IMAP <=> IMAP syncs: saves FETCH BODY.
- the message could still become oversized due to conversion.
- dummy messages resulting from MaxSize should contain a dump of the original
- message's MIME structure and its (reasonably sized) text parts.
- don't SELECT boxes unless really needed; in particular not for appending,
- and in write-only mode not before changes are made.
- problem: UIDVALIDITY change detection is delayed, significantly complicating
- matters.
- some error messages are unhelpful in non-verbose mode due to missing context.
- possibly use ^[[1m to highlight error messages.
- consider alternative approach to trashing: instead of the current trash-before-
- expunge done by mbsync, let MUAs do the trashing (as modern ones typically do).
- mbsync wouldn't do any trashing by itself, but should track the moves for
- optimization. additionally, there should be a mode to move trashed messages to
- the remote store. TrashMode Internal|External, AbsorbRemoteTrash.
- a yet different approach to trashing is treating the trash like a normal mailbox.
- however, this implies a huge working set.
- consider optional use of messages-id (and X-GM-MSGID):
- - detection of message moves between folders
- - recovery from loss of sync state, migration from other tools
|