141 lines
5.5 KiB
Plaintext
141 lines
5.5 KiB
Plaintext
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>
|