[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN
tss at iki.fi
Wed Nov 16 06:57:33 PST 2011
On Wed, 2011-11-16 at 15:49 +0100, Bron Gondwana wrote:
> > > But, I don't see how you can allow reads to see the messages until they are fully committed and indexed and "durable" for whatever level of guarantee you require. And because of that, I don't see how you can allow writes without ordering
> > > enforcement of "this commit is guaranteed to complete".
> > >
> > > Consider:
> > >
> > > * session A starts a write, gets GUID 101
> > > * session B starts a write, gets GUID 102
> > The messages don't get a (G)UID until they are complete and being
> > committed.
> Fair enough. You still need ordering guarantees of the commits themselves though. How are you allocating GUIDs locklessly? Are they based on the order in which your writes actually happened by reading back?
Well, depends on what we're talking about now :) To me GUIDs are 128 bit
identifiers that have no ordering and can easily be generated
locklessly. I don't see much point in having smaller ascending GUID
For the 32 bit IMAP UIDs yes, the idea was to simply append records to a
transaction log and read them back to see how they got ordered, which
gives the messages their UIDs.
More information about the Imap-protocol