MBOX-Line: From dwhite at olp.net  Fri Jun 11 18:54:50 2010
To: imap-protocol@u.washington.edu
From: Dan White <dwhite@olp.net>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] Re: IMAP MOVE extension
In-Reply-To: <201006120251.24779.witold.krecicki@firma.o2.pl>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006120159.05366.witold.krecicki@firma.o2.pl>
	<alpine.OSX.2.00.1006111725170.662@hsinghsing.panda.com>
	<201006120251.24779.witold.krecicki@firma.o2.pl>
Message-ID: <20100612015450.GA4440@dan.olp.net>

On Sat, 12 Jun 2010 01:24:53 +0200 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.

The relevance of a performance hack is not really on topic when discussing
the merits of a change in the protocol, especially if that hack has no
detrimental effect on how the server interacts with clients.

A proposal which does also have performance benefits might make for a good
argument, but debasing server implementations that have found their own
fixes for performance issues is not a good defense.

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

With policy or standards based organizations, I've found the burden is on
the sponsor of the proposal to garner support. I would assume silence as
being indifferent or against change.

On Sat, 12 Jun 2010 02:51:24 +0200 Witold Kr?cicki:
> On Saturday 12 of June 2010 02:27:33 Mark Crispin wrote:
>> If you do believe that, then you are wrong.  I know of multiple clients,
>> including at least one with millions of users, that have undelete as
>> Philip describes.
> Name at least the one with millions of users.

You appear to be attacking server and client implementation choices that
you either don't agree with, or that partially void the need for your
proposed change.

I would suggest focusing your arguments on the benefit of the change to the
protocol itself.

-- 
Dan White

