MBOX-Line: From mrc+imap at panda.com  Tue Nov 15 18:24:17 2011
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:47 2018
Subject: [Imap-protocol] SELECT/EXAMINE clarification of UNSEEN
In-Reply-To: <D454A5E5-BEDE-47E6-909B-2C90463835EE@iki.fi>
References: <C61A1BDF-03DD-4ED9-BFCA-C6183F07DD3E@mac.com>
	<alpine.OSX.1.10.1111141446070.8578@rastawifi.orthanc.ca>
	<1321311798.30750.140660998918417@webmail.messagingengine.com>
	<4EC1A0A5.8051.EFC2A39@David.Harris.pmail.gen.nz>
	<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>
Message-ID: <alpine.OSX.2.00.1111151800340.38075@hsinghsing.panda.com>

On Wed, 16 Nov 2011, Timo Sirainen wrote:
> MSNs still seem like a
> good idea, although UIDs possibly could be strings (but then can you
> copy the same mail into same mailbox to create a duplicate UID?)

That brings up the possibility of GUIDs (and possibly using uint64 instead
of uint32). Unfortunately, this also would cause the loss of strict
ascendency; a principle characteristic that makes IMAP UIDs more useful
than POP3 UIDs.

> Keyword = mailbox mapping might be nice.

If I were to do that, I abolish separate mailboxes as a concept entirely,
and go to named views ala Gmail. That, in turn, would infuriate everybody
that uses a timesharing system style mail store with multiple mailboxes as
separate filesystem objects. A major part of the design of IMAP was to
export pre-existing mail stores.

There's always a tension between those who want a mail access protocol to
export something pre-existing, and those who want it to export their
notion of an ideal.

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.

On the OTHER hand (three hands here?) doesn't that also preclude shared
mailboxes? Oh dear, oh my...

Choices, choices... :)

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.

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.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

