From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.5 required=5.0 tests=DATE_IN_PAST_24_48
	autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 19310 invoked from network); 30 May 2021 22:37:22 -0000
Received: from 1ess.inri.net (216.126.196.35)
  by inbox.vuxu.org with ESMTPUTF8; 30 May 2021 22:37:22 -0000
Received: from orthanc.ca ([208.79.93.154]) by 1ess; Sat May 29 17:47:45 -0400 2021
Received: from orthanc.ca (localhost [127.0.0.1])
	by orthanc.ca (OpenSMTPD) with ESMTP id 6aee187e
	for <9front@9front.org>;
	Sat, 29 May 2021 14:41:04 -0700 (PDT)
From: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>
To: 9front@9front.org
In-reply-to: <E7A78FE36FDAAE545D7DA7EBEEBD1A0E@gmx.com>
References: <E7A78FE36FDAAE545D7DA7EBEEBD1A0E@gmx.com>
Comments: In-reply-to risto.salminen@gmx.com
   message dated "Sat, 29 May 2021 12:44:39 +0300."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9536.1622324463.1@orthanc.ca>
Date: Sat, 29 May 2021 14:41:04 -0700
Message-ID: <0322c68128a95c7e@orthanc.ca>
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: method-oriented shader table-oriented control 
Subject: Re: [9front] upas/fs: copy messages between IMAP folders
Reply-To: 9front@9front.org
Precedence: bulk

> As a detail,
> IMAP, as a protocol, does not support moving
> messages between folders, so moving has to be
> implemented by first copying the message to the
> target folder and then deleting the original
> message from the source folder.  I chose to
> offload this logic to the mail client, as
> presented in the upas/nedmail patch, which
> could also be adapted to acme's Mail.

The IMAP "move" model has always been 'copy + store +flags \deleted'.
This performs the copy operation internally to the IMAP server, so
no data need go over the wire.  I haven't looked at your patch in
detail, but if you have devolved this to the case where a "copy"
between folders on the same server always involves a round trip
through the MUA, this is a horrible pessimization and the patch
should NOT be incorporated as is.

Doing IMAP "right" isn't always easy, and this is a case where you
have to do the extra work in order to do the correct optimization.
You need to reliably figure out if the source and destination paths
in the "move" correspond to the same server+user.  If they do, use
the IMAP COPY command, otherwise fall back to the MUA loop.

--lyndon