[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN

Mark Crispin mrc+imap at panda.com
Tue Nov 15 22:10:32 PST 2011


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.

There are even some systems where ++ is atomic (yes, even if multicore)
and you don't need the mutex.

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.

Of course, the appended mailbox needs to be mutexed over all of this, but
that's less overall concern than the global mutex.


>> If we keep the facility of separate mailboxes, albeit for such

>> functionality as shared mailboxes, then keywords should evolve into named

>> views; and servers should use these and NOT mailbox naming for views.

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

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.


> Some say this has already happened, because the preferred

> view order for email of most users (at least of the ones I've dealt with)

> is NOT ascending UID.


User view order is neither the point nor purpose of ascendency.


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


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

-- Mark --

http://panda.com/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.



More information about the Imap-protocol mailing list