MBOX-Line: From daniel.keen at gmail.com  Tue Jun 15 13:46:55 2010
To: imap-protocol@u.washington.edu
From: Dan Keen <daniel.keen@gmail.com>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] MOVE is a pipeline
In-Reply-To: <4C17D434.5080807@aol.com>
References: <1372616189.4386.1276624386644.JavaMail.root@dogfood.zimbra.com>
	<1276626345.2916.50.camel@kurkku.sapo.corppt.com>
	<484642146.4458.1276626832297.JavaMail.root@dogfood.zimbra.com>
	<4C17CBDA.6070604@gulbrandsen.priv.no> <4C17D434.5080807@aol.com>
Message-ID: <1962E314-5BC3-4A09-B8A2-3C6104C09161@gmail.com>

I would be fine with mandating that MOVE was UID only, but that makes it different from most commands.

In regard to MSN in general, it is still very useful for initial synchronization. We use it every time for that (could go away with CONTEXT=SORT), but then rely upon UID for mutating messages.

Sent from my iPhone

On Jun 15, 2010, at 12:27 PM, John Snow <snowjn@aol.com> wrote:

> Arnt Gulbrandsen wrote:
>> 
>> On 06/15/2010 08:33 PM, Dan Karp wrote: 
>>> I think we can stop there.  UID MOVE, like UID FETCH et al, would have 
>>> no problems with EXPUNGE or VANISHED notifications.  It's MOVE (and 
>>> STORE, etc.) that have the issue addressed in RFC 3501 section 7.4.1. 
>> 
>> I'd be happy if the document specified only UID MOVE, not MOVE. How about the other (would-be) implementers? 
> I'd be fine with that.  In fact, I'd prefer that we removed the sequence set from all commands.  Use UID for everything.
> 
> How does everyone handle a large folder, say 500,000 messages?  In order to process sequence numbers, you have to 
> know which messages are in the set.  The few implementations I've seen do this by loading the messages into a cache.
> This makes some command slow while the cache is loaded.  There is also a limit on how many messages can be loaded
> in the cache.  If UID were the only way to reference a message, then I wouldn't need to cache the message list, I 
> could just work directly from the database.   
>> 
>> Arnt 
>> _______________________________________________ 
>> Imap-protocol mailing list 
>> Imap-protocol@u.washington.edu 
>> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol 
> 
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20100615/6d8a6c27/attachment.html>
