[Imap-protocol] IMAP MOVE extension
snowjn at aol.com
Fri Jun 11 05:02:13 PDT 2010
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
>> 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
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
>> will support this operation not long after it'd be supported by most
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Imap-protocol