- this allows a more transparent and versatile usage of the library as one can simply compile it as-is and then use the builder to configure where we connect and how we connect without having to be concerned about what type is used for the imap::Client / imap::Session
If the `UIDPLUS` extension is supported, the server will reply to
`APPEND` commands with the UID of the new message. This can even be a
list of UIDs if the `MULTIAPPEND` extension is also supported.
Make this information available to the user as the result of an
`AppendCmd`. The added doc strings have links to the relevant RFCs.
Related to #131.
If the QRESYNC (RFC 7162) extension is being used, a FETCH response to a
STORE or UID STORE command with the UNCHANGEDSINCE query attribute will
return the mod sequence ID of the performed operation. This information
is crucial for building efficient caching clients.
If the `QRESYNC` extension (RFC 7162) is being used, `EXPUNGE` responses
will return the new highest mod sequence for the mailbox after the
expunge operation. Access to this value is quite valuable for caching
clients.
Use a helper function in `parse_many_into` to support parsing into
any container that implements Extend. Refactor Capabilities to use it.
Delete ZeroCopy and associated bits.
Move Flag into it's own module in types.
While IDLE, the server sends unilateral responses to notify the client of
changes to the mailbox as they happen. Instead of always exiting the IDLE
on any change, allow the caller to pass a callback function which receives
the messages and returns an action to either Continue IDLE or Stop and exit.
For clients wishing to use the previous behaviour, a callback_stop convenience
function is provided that terminates the IDLE on any change to the mailbox.
EXPUNGE may return either a series of EXPUNGE responses each with
a single message sequence number, or a VANISHED response with a
sequence set of UIDs. This adds a wrapper enum and some associated
iterators to make it easy to handle these in the client.
