MBOX-Line: From snowjn at aol.com  Fri Jun 11 05:02:13 2010
To: imap-protocol@u.washington.edu
From: John Snow <snowjn@aol.com>
Date: Fri Jun  8 12:34:43 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <29965.1276255927.615799@puncture>
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>
	<29965.1276255927.615799@puncture>
Message-ID: <4C1225C5.6050709@aol.com>



Dave Cridland wrote:
> 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?

This Quota issue is why we added move support to the AOL IMAP server. 
We named it XAOL-MOVE.  It is supported by the Thunderbird client.  Of 
course, that
started with us too.
>
>
>> > > 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.
>
Unfortunately, clients and users seem to prefer the trash-can model.  In 
the trash model, the move command really
is necessary.  It's the only way to empty a mailbox that's full to 
quota.  The copy to trash would fail but a move to
trash will not.
>
>> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20100611/5d492b95/attachment.html>
