69 lines
2.9 KiB
Plaintext
69 lines
2.9 KiB
Plaintext
MBOX-Line: From guenther+imap at sendmail.com Fri Jun 11 16:16:36 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: <201006112352.05642.witold.krecicki@firma.o2.pl>
|
|
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
|
|
<201006112113.56572.witold.krecicki@firma.o2.pl>
|
|
<alpine.OSX.2.00.1006111214020.662@hsinghsing.panda.com>
|
|
<201006112352.05642.witold.krecicki@firma.o2.pl>
|
|
Message-ID: <alpine.BSO.2.00.1006111511070.10697@vanye.sendmail.com>
|
|
|
|
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.
|
|
|
|
|
|
|
|
> > 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.
|
|
|
|
|
|
> > 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'?
|
|
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.
|
|
|
|
|
|
Philip Guenther
|
|
Sendmail, Inc.
|
|
|