[Imap-protocol] [noob] multiple fetch responses for the same message?

Bron Gondwana brong at fastmail.fm
Mon Nov 14 12:56:35 PST 2011


On Mon, Nov 14, 2011 at 12:37:42PM -0800, Mark Crispin wrote:

> The second trap is failing to implement message sequence numbers as a

> primary key in the client-facing part. This may be as simple as a vector,

> indexed by message sequence number, to the internal key. You may, if and

> ONLY if there is an exact sematic mapping between IMAP UID and internal

> key, shortcut the UID->MSN->internal mapping.

>

> Too often, I see the shortcut when the semantics aren't the same, and I

> see truly bizarre (and dysfunctional!) implementations of MSN.

>

> I won't tell you about the implementation that, for each command,

> enumerated all the UIDs and then did a bubble sort in order to implement

> MSNs (and UID ranges). Oh I guess I just did. Sorry if that made you puke

> your lunch.


The problem is that the MID is a MVCC snapshot of a particularly un-useful
view of the messages (strictly ascending UID order), with a view lifetime
which is defined, but is very dependent on the specific commands you issue,
so if you want to do one of those actions, you need to handle the snapshot
jumping forwards.

There's no way to get a snapshot of any OTHER view of the messages, so
unless you want the view that MID gives you, you're kinda screwed. You
wind up having to keep a MID to UID mapping even if you don't actually
care about MIDs at all, and you need to update all the MIDs any time
something gets expunged from somewhere in the middle.

In other words, it's an impedence mismatch to what client writers want, and
probably what server writers want too.

They get it wrong because they don't think the way the IMAP protocol thinks,
and they don't think that way because frankly, it's a pretty scummy data
model unless you want to do approximately one and only one thing with the
data: access it in UID order.

Bron.



More information about the Imap-protocol mailing list