MBOX-Line: From guenther+imap at sendmail.com  Fri Jun 11 16:45:43 2010
To: imap-protocol@u.washington.edu
From: Philip Guenther <guenther+imap@sendmail.com>
Date: Fri Jun  8 12:34:43 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: <alpine.BSO.2.00.1006111628220.28689@vanye.sendmail.com>

On Sat, 12 Jun 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.

And hash tables have been a performance hack for 5 decades.

Or do you have an *OBJECTIVE* criteria for what makes something a 
performance hack that the rest of us can use to understand why you refuse 
to use a supported feature of the data structures that we call a 
filesystem?


> > > > IMAP has generally not added features whose sole purpose is to 
> > > > provide support for a particular type of store.  Far more common 
> > > > is that a particular type of store has vetoed a proposed addition.
> > > 
> > > MOVE creates advantage for any kind of single-labeled flat store.
> > 
> > So you agree with Mark that it's only for a particular type of store 
> > that this helps.
>
> No, I'm showing that there is a store in which this helps. There may be 
> other types.

That still sounds like you agree, even though you don't want to.  "There 
may be others" could be said about *anything*.  If there's an example 
that's significantly different than the "single-labelel flat store" for 
which MOVE is an advantage, cite it.


> > > Most of the people here (I'm silently assuming that they are not all 
> > > newcomers) agreed that it is in fact a needed feature.
...
> No, I'm simply assuming that those who are not willing to take part in this 
> discussion do not have an opinion.

I'll just quote those two sentences of yours and say that they are in 
conflict.


> 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.

It's been discussed multiple times in the past (oh, why does no one 
actually read the archives?) how to implement the Trash Can UI on top of 
the IMAP \deleted+EXPUNGE model.  And guess what, that can do something 
the "trash can is a mailbox" model can't: undelete restores the message to 
its original place in the mailbox.


Philip Guenther

