50 lines
2.2 KiB
Plaintext
50 lines
2.2 KiB
Plaintext
MBOX-Line: From tss at iki.fi Wed Nov 16 06:57:33 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Timo Sirainen <tss@iki.fi>
|
|
Date: Fri Jun 8 12:34:47 2018
|
|
Subject: [Imap-protocol] SELECT/EXAMINE clarification of UNSEEN
|
|
In-Reply-To: <1321454946.28208.140660999703561@webmail.messagingengine.com>
|
|
References: <1321346922.6321.140660999083661@webmail.messagingengine.com>
|
|
<4EC268D1.7010404@aol.com>
|
|
<1321364880.3715.140660999182809@webmail.messagingengine.com>
|
|
<alpine.OSX.2.00.1111151258420.38075@hsinghsing.panda.com>
|
|
<20111115233902.GA1071@brong.net>
|
|
<alpine.OSX.2.00.1111151543580.38075@hsinghsing.panda.com>
|
|
<D454A5E5-BEDE-47E6-909B-2C90463835EE@iki.fi>
|
|
<alpine.OSX.2.00.1111151800340.38075@hsinghsing.panda.com>
|
|
<20111116052757.GB12266@brong.net>
|
|
<alpine.WNT.2.00.1111152130220.912@Shimo-Tomobiki.Panda.COM>
|
|
<20111116065154.GA4452@brong.net>
|
|
<C38AC38C-01C6-46FD-A102-9CD703FC2281@iki.fi>
|
|
<1321454138.23977.140660999695557@webmail.messagingengine.com>
|
|
<1321454625.21919.548.camel@hurina>
|
|
<1321454946.28208.140660999703561@webmail.messagingengine.com>
|
|
Message-ID: <1321455456.21919.552.camel@hurina>
|
|
|
|
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
|
|
numbers.
|
|
|
|
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.
|
|
|
|
|
|
|