Simplify POP3 message indexing

[mwpowellhtx]

Per the POP3 specification, UID is an optional feature. Indexing, on the other hand, is considered fundamental; there is no other way to really and truly "index" messages than this. Even the UID depends on the underlying index, but risks falling out of sync with the index in all the client/server roundtrips. Short of providing a best-effort type of strategy pattern resolving index-UID issues, how hard would it be to put a simple IMessageSpool interface in; one in which it was simply index-based and not UID-based. I've got logic in my service that depends on indexing as well; that will save me having to rip that out and replace with UID-based approach (for previously mentioned risks).

[jstedfast]

Even the UID depends on the underlying index, but risks falling out of sync with the index in all the client/server roundtrips.

No.... it really doesn't. The mailbox is locked and messages are not actually deleted until the connection is closed, thus the UIDs and the indexes they map to stay identical for the entire session. More messages may arrive, I suppose, but the messages that exist at the start of the session will not go away until it is closed.

how hard would it be to put a simple IMessageSpool interface in; one in which it was simply index-based and not UID-based.

You mean like all of the index-based APIs that already exist in IMessageSpool? No time at all, because they are already there. Every method has 2 forms: one takes a uid and one takes an index.