MBOX-Line: From witold.krecicki at firma.o2.pl  Fri Jun 11 03:12:57 2010
To: imap-protocol@u.washington.edu
From: Witold =?utf-8?q?Kr=C4=99cicki?= <witold.krecicki@firma.o2.pl>
Date: Fri Jun  8 12:34:43 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <29965.1276250223.982828@puncture>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006111115.19660.witold.krecicki@firma.o2.pl>
	<29965.1276250223.982828@puncture>
Message-ID: <201006111212.57771.witold.krecicki@firma.o2.pl>

On Friday 11 of June 2010 11:57:03 Dave Cridland wrote:
> On Fri Jun 11 10:15:18 2010, Witold Kr?cicki wrote:
> > On Friday 11 of June 2010 10:59:31 Dave Cridland wrote:
> > > Depending on your server design, this is either very easy, or else
> > > very hard - of course, since it's optional, it'd seem likely that
> > > where it's hard it'd not be supported.
> > 
> > That's sure, that's why it's an option.  In most popular IMAP
> > servers that use
> > Maildirs this is a simple 'move' operation, with I/O cost of next
> > to nothing
> > (assuming that the whole user account is on one FS of course).
> 
> ... And COPY is a "link" operation, with, equally, next to no I/O.
assuming that underlying FS supports hard linking and that the messages are  
immutable (remember that not only IMAP accesses messages).

> > > One thing that concerns me is that there is no way to undo this
> > > operation - traditionally, only EXPUNGE and DELETE have been
> > > irrevocable actions in IMAP, this adds one more.
> > 
> > I don't see problem with that. And it is still revocable as long as
> > we don't
> > care for changed UID (you can always select second mailbox and move
> > messages
> > back). No data is harmed here.
> 
> The changed UID is significant - it has the effect of invalidating
> the cache. This may not be a showstopper, I'm just raising it as an
> issue.
The question is - if the user uses st/cp/ex it's as irrevocable as move, so 
why bother?
  
> > > The way to combat this is to make it merely mark \Deleted the
> > > original message - except then this eradicates any benefit to the
> > > command at all for clients. (Since one could either do MOVE/UID
> > > EXPUNGE, or else COPY+STORE/UID EXPUNGE).
> > 
> > That destroys the whole idea of atomic MOVE command, from both
> > server and
> > client side.
> 
> Yes, this is true.
> 
> > > And there has to be very significant advantage for clients,
> > 
> > across a
> > 
> > > wide deployment, for most clients to bother implementing it -
> > 
> > right
> > 
> > > now, I don't see it.
> > 
> > Have you ever tried to 'move to trash' eg. 2000 messages from inbox?
> > With current copy/store/expunge routine it takes (at least on
> > servers that
> > I've tested) really really long times.
> 
> I'm not convinced this is a terribly common operation. If it is, and
> if this causes your server to be slow, one option would be to
> optimize this case better. 
It is common with users with long e-mail history and inboxes containing >10k, 
and sometimes even >100k mails.

> > Another real life example is a situation when user wants to move
> > contents of
> > his INBOX to 'old-mail' mailbox with quota enabled and INBOX larger
> > than half
> > of his quota.
> 
> In some cases, that can be very quick indeed - just a RENAME command.
In cases when you want to move 'old' (older than  1 month) mail - it doesn't 
work. And that is a common operation.

> > Other thing is that most of the client support 'move' operation by
> > means of
> > cp/st/ex, and adding support for simplified 'MOVE' mode should not
> > be such a
> > huge programming effort.
> 
> Unless, of course, they implement a move via copy/store instead,
> aiming to be more IMAP-like, in which case this doesn't help at all.
Most of the clients I've seen (and I've investigated a few of them lately) do 
cp/st/ex (with expunge sometimes delayed, but not for long). 

> Besides, lots of things are not a huge programming effort - I'd be
> curious as to how many client developers would be keen to write this
> alternate codepath in.
One have already done it, and that wasn't me :)
Lots of IMAP clients are open source, and I'm pretty sure that TB/Claws/KMail 
will support this operation not long after it'd be supported by most popular 
IMAP servers.

-- 
Witold Kr?cicki

Grupa o2 Sp??ka z o.o., ul. Jutrzenki 177, 02-231 Warszawa,
KRS 0000140518, S?d Rejonowy dla m.st. Warszawy, 
Kapita? zak?adowy 377.298,00 z?., NIP 521-31-11-513

