Constructor RemoteFolderWindowObservation

Namespace

MailFathom.Application.Synchronization.Reconciliation

Assembly

MailFathom.Application.dll

RemoteFolderWindowObservation(IReadOnlyList<RemoteEmailFlagObservation>, IReadOnlyList<ImapUid>, ulong?)

What the mail server said about one bounded window of occurrences the local copy already holds.

public RemoteFolderWindowObservation(IReadOnlyList<RemoteEmailFlagObservation> Observations, IReadOnlyList<ImapUid> UnchangedUids, ulong? FolderHighestModSeq)

Parameters

Observations IReadOnlyList<RemoteEmailFlagObservation>

The occurrences the server described, with the flags it reported for each.

UnchangedUids IReadOnlyList<ImapUid>

The occurrences the server proved it still holds without describing them, because nothing about them has changed since the modification sequence the caller supplied.

FolderHighestModSeq ulong?

The folder's highest modification sequence at the moment of the read, or null when the server reports none. A caller records it only after a pass that covered the whole folder.

Remarks

The two lists together are the folder's answer about what it still holds, and a UID in neither of them is one the folder no longer holds. That is the whole detection mechanism for a message deleted on the server, so an implementation may place a UID in UnchangedUids only where the server positively said the message is still there — a listing of the surviving identifiers, or a vanished report that named the ones it is not among. Silence is never enough: a modification-sequence-limited fetch says nothing about a message that was deleted and nothing about one that did not change, and treating the second answer as the first would leave a deleted message stored forever.

Nothing here carries a message. A UID, a flag snapshot, and a sequence number are what deciding existence needs, and the read that produces them cannot set the remote \Seen flag.