Add IMAP UIDPLUS support (RFC 4315) - #115
Conversation
Adds UIDPLUS extension support so callers can recover the UIDs the server assigns on APPEND/COPY and target expunges by UID: - appendFullUID: like appendFull, returns the APPENDUID response code - copyUID / copyUIDs / copyUIDR: UID COPY returning the COPYUID code - uidExpunge / uidExpungeR: UID EXPUNGE over a UID set or range New types AppendUID and CopyUID, the UIDSet alias, and the APPENDUID/COPYUID/UIDNOTSTICKY status codes with their parsers. sendCommandWithResponse exposes the tagged ServerResponse so the response codes can be read. The existing appendFull/copyFull keep their old signatures by discarding the UID result. Covered by new parser cases in baseTest and a dedicated imapUIDPlusTest group exercising the API against scripted server responses.
bddf0fa to
0086c02
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0086c027da
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| , do { string "UIDVALIDITY" >> space | ||
| ; num <- many1 digit | ||
| ; return $ UIDVALIDITY_sc $ read num } | ||
| , string "UIDNOTSTICKY" >> return UIDNOTSTICKY |
There was a problem hiding this comment.
Parse UIDNOTSTICKY from untagged SELECT responses
When selecting a mailbox whose UIDs are not persistent, RFC 4315 sends UIDNOTSTICKY in an untagged * NO [UIDNOTSTICKY] ... response, followed by the tagged SELECT completion. Adding it only to pDone cannot observe that valid response: pSelect consumes the untagged line with its catch-all branch and discards it, so the new constructor is never surfaced for its specified use case. Parse this response in the untagged SELECT path and retain it in the selected-mailbox result.
Useful? React with 👍 / 👎.
|
This one looks AI generated, it’s perfectly ok, but i would like to reserve some time on familiarizing myself with RFC. So I ncan read it more deeply, unless @mpscholten you are using it in the production already |
|
I don't use these functions in prod yet, so feel free to take time to read the RFC :) |
What
Adds support for the IMAP UIDPLUS extension (RFC 4315), so callers can recover the UIDs the server assigns during
APPEND/COPYand can expunge messages targeted by UID.New API (
Network.HaskellNet.IMAP)appendFullUID— likeappendFull, but returns theAPPENDUIDresponse code (the UID assigned to the appended message)copyUID/copyUIDs/copyUIDR—UID COPYvariants returning theCOPYUIDresponse code (single UID, UID list, UID range)uidExpunge/uidExpungeR—UID EXPUNGE, removing only the\Deletedmessages within a given UID set/rangeNew types (
Network.HaskellNet.IMAP.Types)AppendUID,CopyUID, and theUIDSetaliasStatusCodeconstructorsAPPENDUID_sc,COPYUID_sc,UIDNOTSTICKY, with parsers inIMAP.ParsersPlumbing
sendCommandWithResponseexposes the taggedServerResponseso the new response codes can be read;sendCommandis now defined in terms of it.appendFull/copyFullkeep their old signatures (they discard the UID result), so this is backwards compatible.Tests
baseTestfor theAPPENDUID/COPYUID/UIDNOTSTICKYresponse codes.imapUIDPlusTestgroup exercising the new API against scripted server responses (verifying both the bytes sent and the parsed UID result).All new tests pass locally (
cabal test, GHC 9.8.4).🤖 Generated with Claude Code