mbsync/TODO

have a look at libpathfinder.

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

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

!srec->msg[t] || (srec->msg[t]->status & M_DEAD)

use UID EXPUNGE! (rfc4315 (obsoletes rfc2359))

quotas are weird, they make close() fail.

clarify error cases of transactions.

clarify UID 0 vs. < 0 returns vor store_msg & find_msg.

create dbg_srec(srec, fmt, ...).


make SSL certificate validation more automatic.

allow excluding particular boxes from a wildcard spec.

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

add asynchronous operation to remote mailbox drivers. this is actually
what prevents us from simply using c-client and thus becoming mailsync.

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).

fix maildir_{open_store,list} to handle partial names (last char not slash).

add a way to automatically create and sync subfolders.

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)