[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN
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
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
> 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
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
> 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