[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN

Bron Gondwana brong at fastmail.fm
Tue Nov 15 21:27:57 PST 2011


On Tue, Nov 15, 2011 at 06:24:17PM -0800, Mark Crispin wrote:

> On the other hand, replacing mailboxes with named views (and the resulting

> abolition of COPY) makes GUIDs more viable. Synchronization would always

> be with the "all" view, and thus we can keep strict ascendency even though

> messages may come and go in a certain view.


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.


> On the OTHER hand (three hands here?) doesn't that also preclude shared

> mailboxes? Oh dear, oh my...


Indeed it does. Any concept of "shared namespace" - either you still have
multiple separate ID "sets" still... or you get a global lock.


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


> My understanding is that Google perceived keywords as not commonly

> implemented, and thus needing to do view/mailbox mapping. It's been a

> major problem; a classic case of kludge tower building because it was

> perceived that they couldn't do it right to begin with.

>

> >Using more command pipelining would be

> >nice (e.g. search <stuff> | store <here>).

>

> I've thought of that, but in a more limited context of "apply search

> criteria" as the sequence for a command.


MVCC on a search/sort rather than on the UID ordering (which is what
MID gives) is right at the top of my list - along with the ability to
reconnect said MVCC after session drop - which happens more and more
with the smartphoney things of today.

Not requiring multiple parallel connections to be informed of changes.

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.

A test suite up-front (like Timo's excellent ImapTest) which server
makers can test their implementations against.

A lot of it is basically "look at the insane things that client/server
authors have come up with to kludge around IMAP not expressing what
they needed" - which is the evolutionary approach...

Bron.



More information about the Imap-protocol mailing list