MBOX-Line: From witold.krecicki at firma.o2.pl  Fri Jun 11 16:24:53 2010
To: imap-protocol@u.washington.edu
From: Witold =?utf-8?q?Kr=C4=99cicki?= <witold.krecicki@firma.o2.pl>
Date: Fri Jun  8 12:34:43 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <alpine.BSO.2.00.1006111511070.10697@vanye.sendmail.com>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006112352.05642.witold.krecicki@firma.o2.pl>
	<alpine.BSO.2.00.1006111511070.10697@vanye.sendmail.com>
Message-ID: <201006120124.53714.witold.krecicki@firma.o2.pl>

On Saturday 12 of June 2010 01:16:36 Philip Guenther wrote:
> On Fri, 11 Jun 2010, Witold Kr?cicki wrote:
> > On Friday 11 of June 2010 23:17:56 Mark Crispin wrote:
> > > On Fri, 11 Jun 2010, Witold Kr?cicki wrote:
> > > >> MOVE provides no real benefit to such stores; yet those stores are
> > > >> the only ones that can actually implement it properly.
> > > > 
> > > > Database-backed stores can implement it properly and can have
> > > > performance boost.
> > > 
> > > So, you postulate a database which is designed to have a performance
> > > boost in the case of this extension, yet can not implement the base
> > > specification without a performance cost.
> > 
> > COPY is by definition a slow operation. Using hardlinks etc. is a
> > performance hack, not a normal method.
> 
> 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.

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

> > > This is not the first time this discussion has taken place.
> > > 
> > > Every few years, a newcomer comes along and says "I have this simple
> > > solution that you all should adopt."  Then more experienced people try
> > > to explain the complexities of the situation.
> > 
> > Currently You are the only one more experienced that is trying to explain
> > the complexities of the situation. Most of the people here (I'm silently
> > assuming that they are not all newcomers) agreed that it is in fact a
> > needed feature.
> 
> You're claiming that silence is assent with your side and not the others'?
No, I'm simply assuming that those who are not willing to take part in this 
discussion do not have an opinion.

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

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.

-- 
Witold Kr?cicki

Grupa o2 Sp??ka z o.o., ul. Jutrzenki 177, 02-231 Warszawa,
KRS 0000140518, S?d Rejonowy dla m.st. Warszawy, 
Kapita? zak?adowy 377.298,00 z?., NIP 521-31-11-513

