MBOX-Line: From brong at fastmail.fm  Thu May 26 15:36:37 2011
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:46 2018
Subject: [Imap-protocol] History question.
In-Reply-To: <4DDEB7EB.2090508@aol.com>
References: <4DDEA412.6030305@aol.com>
	<alpine.BSO.2.00.1105261253510.31737@morgaine.smi.sendmail.com>
	<4DDEB7EB.2090508@aol.com>
Message-ID: <20110526223637.GA29831@brong.net>

On Thu, May 26, 2011 at 04:28:27PM -0400, John Snow wrote:
> Philip Guenther wrote:
> >On Thu, 26 May 2011, John Snow wrote:
> >>My question is simply, why?  Why is the sequence number needed
> >>when the command specified a UID, and the UID must be included
> >>in the response.  Seems to me the UID command should have a UID
> >>response. snow.
> >
> >Right now, a client can parse a FETCH response at any time,
> >inserting it into its cache without having to consider any context
> >of pending commands.  Indeed, the server can send FETCH responses
> >at any time (modulus TCP flow-control/deadlock concerns), and it's
> >*required* to do so for flag changes.  Sometimes using the UID and
> >sometimes using msgno would make such unsolicited FETCH responses
> >ambiguous.
> >
> >Philip Guenther
> 
> A UID fetch response could just as easily be handled at any time.
> 
> From the example:
> 
>   Example:    C: A999 UID FETCH 4827313:4828442 FLAGS
>               S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
>               S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
>               S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
>               S: A999 OK UID FETCH completed
> 
>       why not this instead?
> 
>   Example:    C: A999 UID FETCH 4827313:4828442 FLAGS
>               S: * UID 4827313 FETCH (FLAGS (\Seen))
>               S: * UID 4827943 FETCH (FLAGS (\Seen) )
>               S: * UID 4828442 FETCH (FLAGS (\Seen) )
>               S: A999 OK UID FETCH completed

Apart from the more complex parser.  Parsing IMAP is
hairy enough as it is.

What I would like to see (if I was writing "IMAP" from
scratch) is putting the "UID" part as a generic search
expression.  So you would either do:

A999 FETCH 1:5 FLAGS

or

A999 FETCH (UID 4827313:4828442) FLAGS

or indeed:

A999 FETCH (OR UNSEEN FLAGGED) (WINDOW 1:20) FLAGS

The ability to request the first "N" messages that match
a particular filter (even more so if you could apply a sort
upfront as well) would be very handy.

And if you were doing something expensive like a full body
search, then being able to sort the result by something
trivial (like REVERSE SENTDATE) and then apply the search
only until you had filled your request window could
potentially save a lot of IO.

But none of that is a good reason to have a conditionally
mutating response format.

Bron ( though I'd love for it to be easier to require IDLE to
       spit out UIDs on every response )

