[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN

Bron Gondwana brong at fastmail.fm
Tue Nov 15 22:51:54 PST 2011

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".


More information about the Imap-protocol mailing list