[Imap-protocol] IMAP MOVE extension

[John Snow]

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://mailman2.u.washington.edu/pipermail/imap-protocol/attachments/20100611/5d492b95/attachment-0001.html