109 lines
4.6 KiB
Plaintext
109 lines
4.6 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Tue Nov 15 22:51:54 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
Date: Fri Jun 8 12:34:47 2018
|
|
Subject: [Imap-protocol] SELECT/EXAMINE clarification of UNSEEN
|
|
In-Reply-To: <alpine.WNT.2.00.1111152130220.912@Shimo-Tomobiki.Panda.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>
|
|
Message-ID: <20111116065154.GA4452@brong.net>
|
|
|
|
On Tue, Nov 15, 2011 at 10:10:32PM -0800, Mark Crispin wrote:
|
|
> On Wed, 16 Nov 2011, Bron Gondwana wrote:
|
|
> >The other problems with strict ascendency is that it requires a global lock
|
|
> >for the duration of any append, over whatever scope you require the
|
|
> >ascendency in. As you expand out from a single mailbox to the scope of an
|
|
> >entire user, you expand the scope of that global lock.
|
|
>
|
|
> Not necessarily. If the GUID is expanded to a uint64 then there's no
|
|
> reason why the GUID assignment can't be simply:
|
|
> <acquire mutex>
|
|
> guid = ++lastguid;
|
|
> <release mutex>
|
|
> You don't care if the GUID space is holey; and with a uint64 you don't
|
|
> even care if you end up losing some.
|
|
|
|
No, it's not that easy. You need every view before to not include it,
|
|
and every view afterwards to include it.
|
|
|
|
> There are even some systems where ++ is atomic (yes, even if multicore)
|
|
> and you don't need the mutex.
|
|
|
|
That's cheap - making sure you never return these out of order is not.
|
|
|
|
> The real issue is MULTIAPPEND and its interaction with UIDPLUS.
|
|
> Fortunately, you don't have to assign UIDs as messages are uploaded; you
|
|
> can defer that until the uploads are completed. Since you now know how
|
|
> many messages you are adding, you can claim an entire range of GUIDs via
|
|
> <acquire guid mutex>
|
|
> guid = lastguid += nappends;
|
|
> <release guid mutex>
|
|
> Then assign the already-claimed GUIDs at leisure while checking in the
|
|
> append.
|
|
|
|
Only by blocking all reads while this is happening.
|
|
|
|
> Of course, the appended mailbox needs to be mutexed over all of this, but
|
|
> that's less overall concern than the global mutex.
|
|
|
|
The appended ID scope, if we're using keyword/flags instead of folders, yes.
|
|
|
|
> >Which no longer have the strict ascendency property, rendering it somewhat
|
|
> >worthless.
|
|
>
|
|
> The purpose of strict ascendency is for synchronization. Because these are
|
|
> multiple views on a single object, you don't need that at the level of a
|
|
> view.
|
|
|
|
This is valuable purely for a client that does a full synchronisation. For
|
|
something which uses MIDs (which only have value within a held TCP connection)
|
|
|
|
> A view should compromise either on ascendency or on prohibition of insert.
|
|
> I would do the compromise on prohibition of insert, which already happens
|
|
> if you have a view that focuses on a keywords.
|
|
|
|
Someone else can insert something which matches your view - unless you have
|
|
a non-updating view.
|
|
|
|
> >Not requiring multiple parallel connections to be informed of changes.
|
|
>
|
|
> Why on earth would any well written client require multiple parallel
|
|
> connections? Never mind why poorly-written clients need it.
|
|
|
|
How many clients make multiple parallel connections out there? Most of
|
|
them. For fucks sake - it's like you're trying to be obtuse. They
|
|
have multiple connections so they can keep IDLE on a folder or two while
|
|
they update the STATUS counts on other folders, amongst other things.
|
|
|
|
And a separate connection to send email, and a separate connection to
|
|
get a contacts list, and ...
|
|
|
|
> >And of course the low handing fruit: UTF-8 throughout, a more regular
|
|
> >syntax which simplifies parsing and has space for extentions later so
|
|
> >that every command doesn't have its own unique, slightly different
|
|
> >parser.
|
|
>
|
|
> Which will work great until someone wants to do something that doesn't fit
|
|
> within the regular syntax (and/or wants to "improve" the syntax). Enter
|
|
> the flames that your insistance upon syntax regularity is an evil plot to
|
|
> hinder progress, cause loss of market window, and deny little girls their
|
|
> very own pony.
|
|
>
|
|
> You will discover that phenomenum soon enough. Oh, and don't believe that
|
|
> you can enforce protocol integrity. You'll learn what "being microsofted"
|
|
> and "embrace, extend, destroy" means.
|
|
|
|
Oh, it's bound to happen. That's when the next young buck comes along and
|
|
comes up with something "better".
|
|
|
|
Bron.
|
|
|