MBOX-Line: From dave at cridland.net  Fri Jun 11 04:32:07 2010
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:43 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <201006111212.57771.witold.krecicki@firma.o2.pl>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006111115.19660.witold.krecicki@firma.o2.pl>
	<29965.1276250223.982828@puncture>
	<201006111212.57771.witold.krecicki@firma.o2.pl>
Message-ID: <29965.1276255927.615799@puncture>

On Fri Jun 11 11:12:57 2010, Witold Kr?cicki wrote:
> 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).
> 
> 
Messages in an IMAP message store *are* immutable, no matter what  
else might access the messages. And really, don't Windows, UNIX, and  
Mac filesystems support hardlinking now?


> > > > 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?
> 
> 
Because in general, it's better to work *with* IMAP, rather than  
*against* it, if you're designing extensions, and indeed mail stores.

> > > 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.

Oh, I know it happens. Just not sufficiently often as to be described  
a common operation.

> > > 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.
> 
> 
Is it that slow? Really?


> > > 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).
> 
> 
Delaying expunge is quite sensible - it's the "empty trash" operation  
in IMAP. In general, I'd rather encourage client authors to use the  
spec sensibly, rather than encourage them to ignore how the model  
works.

FWIW, the majority of move-like behaviour I've seen is to a  
trash-can, and that's something I'd much rather not encourage.


> > 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.

Perhaps. But many extensions which save a lot more effort haven't  
been implemented very fast at all, even with quite wide support.

The open-source-ness of the client appears to have very little effect  
on this, either.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

