MBOX-Line: From dave at cridland.net  Mon Jun 14 03:13:57 2010
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <201006120124.53714.witold.krecicki@firma.o2.pl>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006112352.05642.witold.krecicki@firma.o2.pl>
	<alpine.BSO.2.00.1006111511070.10697@vanye.sendmail.com>
	<201006120124.53714.witold.krecicki@firma.o2.pl>
Message-ID: <29965.1276510437.099598@puncture>

On Sat Jun 12 00:24:53 2010, Witold Kr?cicki wrote:
> On Saturday 12 of June 2010 01:16:36 Philip Guenther wrote:
> > Uh, what?  It sounds like you're saying that you're going to  
> build a
> > system where MOVE is fast (so single message rename is fast) but  
> then
> > intentionally *not* take advantage of the design to use hardlinks  
> to make
> > COPY fast.  Claiming that using hardlinks is "not a normal  
> method" when
> > it's been in use for better than a decade requires some  
> justification.
> Even if used for over a decade it is STILL a performance hack.
> 
> 
This is amusing. Your argument appears to be that a sensible, common,  
implementation of a mandatory protocol feature is, somehow,  
undesirable.

Your overall argument also appears to be that:

a) MOVE is simpler for client authors. However, client authors would  
still have to move messages without this extension, hence have to  
provide multiple codepaths to achieve the same - really quite simple  
- facility.

b) MOVE may be simpler for server authors. However, server authors  
who cannot implement COPY are themselves at a disadvantage.

c) It doesn't matter if MOVE is non-atomic, or introduces a new  
irreversable removal of data from a mailbox. This sends shivers up my  
spine. This is surely not an extension critical enough to break IMAP  
semantics, is it?

d) If MOVE turns out to be hard in an existing, conformant  
implementation, then the implementation is somehow broken.

> > That's odd, as I believe I saw messages from two people (Dave and  
> Arnt)
> > saying that it seems unnecessary.  As a former mail store  
> developer
> > (single-instance, file per message with DB indexes, style), I  
> agree with
> > them that this seems unnecessary and not condusive to IMAP
> > interoperability.  I.e., *this* part of the previous silence  
> disagrees
> > with you.
> I've talk with Arnt and he thinks that it it a good idea.
> 
> 
Yes, I agree it's a good idea, too. But the barriers to it are just  
far, far too large to be worthwhile overcoming, given the scope of  
the extension. An extension like this you really want to be  
implementable *everywhere*, and this just doesn't feel right.


> Daves argument that the idea of 'trash can' is broken and people  
> should just
> delete their mails (or IMAP should create a 'trash can' model) it's  
> IMHO
> simply out of this world - people want to have a trash can and be  
> able to
> recover deleted e-mails.

1) I am not advocating that "people should just delete their mails".  
IMAP has a two phase delete, so I *am* advocating that clients - not  
people - should just mark emails as deleted.

2) I concur that people like the trash can metaphor, and would  
encourage client authors to *use* IMAP's facilities to model same.

3) A trash-can, like IMAP's \Deleted flag, is a model conforming to a  
two-phase delete, from which the first phase is recoverable. The  
\Deleted flag means the first phase can be reversed entirely, whereas  
a trash-can mailbox - being bolted on to IMAP without the server's  
knowledge - cannot be. So to characterise my position as not wishing  
to allow people to recover deleted emails is just being silly.

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

