41 lines
1.9 KiB
Plaintext
41 lines
1.9 KiB
Plaintext
MBOX-Line: From snowjn at aol.com Tue Jun 15 12:27:48 2010
|
|
To: imap-protocol@u.washington.edu
|
|
From: John Snow <snowjn@aol.com>
|
|
Date: Fri Jun 8 12:34:44 2018
|
|
Subject: [Imap-protocol] MOVE is a pipeline
|
|
In-Reply-To: <4C17CBDA.6070604@gulbrandsen.priv.no>
|
|
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>
|
|
Message-ID: <4C17D434.5080807@aol.com>
|
|
|
|
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
|
|
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20100615/49b4be45/attachment.html>
|