mbsync/TODO

find out why mutt's message size calc is confused.

f{,data}sync() usage could be optimized by batching the calls.

add some marker about message being already [remotely] trashed.
real transactions would be certainly not particularly useful ...

check whether disappearing (M_DEAD) messages (due to maildir rescans) are
properly accounted for by the syncing code.

make sync_chans() aware of servers, so a bad server (e.g., wrong password)
won't cause the same error message for every attached store.

make SSL (connect) timeouts produce a bit more than "Unidentified socket error".

network timeout handling in general would be a good idea.

unify maildir locking between the two UID storage schemes.
re-opening the db may be expensive, so keep it open.
but keeping lock for too long (e.g., big message downloads) may block other
clients. auto-release lock after 500 ms?

kill the concept of an INBOX, it is a relic from single-channel operation.
if somebody needs it, he can have two stores with different Paths. the path
can name a single (in-)box (curr. broken with maildir). an empty box name
actually means empty, so the IMAP mailbox should use INBOX for Path (can't
make that the default, as it would mess up the NAMESPACE).

add daemon mode. primary goal: keep imap password in memory.
also: idling mode.

parallel fetching of multiple mailboxes.

set_flags:
- imap: grouping commands for efficiency
- callback should get the flags actually affected. but then, why could flag
  changes fail at all?

add streaming from fetching to storing.

handle custom flags (keywords).

handle google IMAP extensions.

use MULTIAPPEND and FETCH with multiple messages.

create dummies describing MIME structure of messages bigger than MaxSize.
flagging the dummy would fetch the real message. possibly remove --renew.
note that all interaction needs to happen on the slave side probably.

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.

possibly request message attributes on a per-message basis from the drivers.
considerations:
- record non-existing UID ranges in the sync database, so IMAP FETCHes needn't
  to exclude anyway non-existing messages explicitly.
- when detect unborn pairs and orphaned messages being gone? implied by expunge:
  with trashing, by local driver, or of messages we deleted in this run. the
  remaining cases could be handled by automatic periodical cleanup passes, an 
  explicit --cleanup action, or be implied by one of the other actions.
- the benefit of this is questionable, as fine-grained requests will result
  in sending huge amounts of data, and upstream is often way slower than
  downstream.

maildir: possibly timestamp mails with remote arrival date.

maybe throw out the ctx->recent stuff - it's used only for one info message.

possibly use ^[[1m to highlight error messages.

consider alternative trash implementation: trash only messages we delete,
and trash before marking them deleted in the mailbox. downside: all other
programs have to do the same. and what if the deleted flag is unset?

items out of scope of purely UID based approach:
- detect message moves between folders
- recovering from UIDVALIDITY change (uw-imap < 2004.352 does this a lot)