For MR37 one of the commits introduced an optional way to allow message sequence IDs to be used for FETCH requests.
The RFC specifies that message UIDs must be numbers, if I'm reading it correctly, especially since they must increment in value for newer messages.
In imap-d the message IDs are strings as this is simpler than casting back and forth from integers and it simpler for SIL. I suggested that for the FETCH calls in the API the message ID could be prefixed with a '#' to indicate that it should be interpreted as a message sequence ID (i.e., 1 for the first message in the mailbox, 2 for the second...), and a missing '#' just indicates a UID as before. Since UIDs must be numbers there can't be a conflict and so this should be backwards compatible and work fine.
Selecting numbers by message sequence ID is useful -- I wanted it to simply iterate through the messages in a mailbox. The alternative is to either do a blanket search to fetch all the UIDs in a mailbox, or do to a FETCH UID n for each message before the UID FETCH ... itself, which wasteful.
If the '#' proposal is too on-the-nose then I guess the alternative is to have fetchByUid or fetchBySeqId alternatives for each of the FETCH functions, which feels a bit verbose and wouldn't suit SIL. Or perhaps to have an extra parameter indicating the type of ID or to use a special type for the ID which indicates whether it's UID or SeqID.
For MR37 one of the commits introduced an optional way to allow message sequence IDs to be used for
FETCHrequests.The RFC specifies that message UIDs must be numbers, if I'm reading it correctly, especially since they must increment in value for newer messages.
In imap-d the message IDs are strings as this is simpler than casting back and forth from integers and it simpler for SIL. I suggested that for the
FETCHcalls in the API the message ID could be prefixed with a '#' to indicate that it should be interpreted as a message sequence ID (i.e., 1 for the first message in the mailbox, 2 for the second...), and a missing '#' just indicates a UID as before. Since UIDs must be numbers there can't be a conflict and so this should be backwards compatible and work fine.Selecting numbers by message sequence ID is useful -- I wanted it to simply iterate through the messages in a mailbox. The alternative is to either do a blanket search to fetch all the UIDs in a mailbox, or do to a
FETCH UID nfor each message before theUID FETCH ...itself, which wasteful.If the '#' proposal is too on-the-nose then I guess the alternative is to have
fetchByUidorfetchBySeqIdalternatives for each of theFETCHfunctions, which feels a bit verbose and wouldn't suit SIL. Or perhaps to have an extra parameter indicating the type of ID or to use a special type for the ID which indicates whether it's UID or SeqID.