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.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17352 invoked from network); 31 May 2021 11:53:08 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 31 May 2021 11:53:08 -0000 Received: from mout.gmx.net ([212.227.17.20]) by 1ess; Mon May 31 07:44:22 -0400 2021 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1622461457; bh=3DAfS7eRlLFxRUEkrV9Y9CbmWUGNq3hRZt2ratm/8BA=; h=X-UI-Sender-Class:From:Date:To:Subject:In-Reply-To; b=SO5ciD6emCc2qYiWxr9qNDQTfkly9izIeI2RKDo5Ibjw1livQatzssIs31f57o+k8 kGa3iHhHu/X7NsCCdqOrBVYs2ryDnSdGbaq2dJvo5FXABDNjg6HNPsEfSkhcllNOH+ ACO/Z77EkEja0Mbcg0TE+tXzyi4t66I2cW2rZMJ8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from purple.my.domain ([84.248.3.213]) by mail.gmx.net (mrgmx105 [212.227.17.174]) with ESMTPSA (Nemesis) id 1N1OXT-1lQ7vC06zD-012t2R; Mon, 31 May 2021 13:31:41 +0200 Message-ID: From: Risto Salminen Date: Mon, 31 May 2021 14:31:10 +0300 To: 9front@9front.org In-Reply-To: <0322c68128a95c7e@orthanc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:Z6uNRf5JMORm+T58sF4ZxRFuFZLH/l2+IlGlbPT8PCRont2jIYN E/iaeoodPhGKB/jTu6H/01t8/mNhxAswWq4iburtRdO6n0HrAg9/4pwvtjeP7xc3PYT9QH2 xDreX57WESg+I/Q028O9gcQiI2j2E18HTCnI5JTOzQ83KCtvL0vLgp5KBUfFZFu2xdqjBq2 aDPjjHmWLFqIxtotuyU7A== X-UI-Out-Filterresults: notjunk:1;V03:K0:8YF5KIblxQI=:YifUYUc6lVaAgaPx2jOJmC Aij2o5hG+c9TA2pArozE65IxII/fAMwBHFF79OcQFLG0lQBYIgWH1cv5kieDpFTLtl4dVYbUs 7h8hMxBtAm+dQpogxMjFvJAVbzar9QT9x3FmqpW7XIzhXMYI3I/wkKGdaI/I1CKUNrZP3tvMn N6lcQ+3Is+geMID6TFHHKmJiPVzgTGpIHaZTLsyaNE/9P9fOG8ZS5ZSXh9Vz4C48S3af8L0eI t5R8HQtgZOWmD0JIW2llyedc3eLGPbeZcYgGWeUYaCILkeyrbu9kX202VWVDasuwP5UmNYuiR 4VUzJlFGy6sQx3PsaEgXghZg7HcT5zbB+t2WvJ99M7NdSbVke8EXP5xnueHpGKKmJGUNq/wVO FRocMqpRRzllFSzxwr9si4WmdZevGlpPh7AeoXwM9lwLgi4M750fvW3oplqUvyChL+/tUERJG lm3jR0CXVIyvN3H2ZF7pPWiMC10c0Kn6TPup784dDaXq++Gz9ZYiWJ8W5nw471Jw7D27pkRJ6 cl25/OVjSHw0Wbe7HkHoOlB/6Gmc2qSiFFiZBcCuy2sut59oMuNDH3PoxUvXx4ewAgjs3bMw5 jLZEjEn143g0mfq+FB3kN/LRZmMEIf2KADPPzGCYuTDDSxQ3v/cCVS2rAzrFJY9V/Tf6u0g9c 6L2LUQMsG7nPZqpIipLhtg70nnaUH2mbkeddTC8/N/m/dU4Ua8LwF6x6lspLiyRd7roH60R7P 0ie0lGehGTfDZMylFwX+lNVuBApzS0JdUNK3BT18VYwiVrEqYLtmLpwODx7w9j+3HsS5hztzM uzwatWgx2ofI/kM5U+o6OM5tlSPbb2tjN6mVgeyITBCb5QaN0IQeFubtEGzbS3k7Npcnsgbfm 5hs9OE1T/ivb5KzqGZkrYOGX5vXSFQAs87n+ObD+ftKVaPC+LMfGcag7l6spYVldONsNOrt/0 JhEcqiMBP/A+9owMfBNZtwcF3XfYwf0+IavDURdLAzBK5olx/sr+JZVBFevEcbxb6WYMiRWgu JQWnOZse1T4H1qvIcVD1TGBeCvgwZciPHNFTIOy+p5WQQ+00q9mFk7zMQ+Xmoa/SkHV240Xu1 a9+py50lPogWN8dh3aijNh3mzBh5Pb71A8I0fWJi9zJw+qKcRR+WMEMXA== List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: optimized AJAX over WEB2.0 full-stack framework just-in-time interface Subject: Re: [9front] upas/fs: copy messages between IMAP folders Reply-To: 9front@9front.org Precedence: bulk Hello, lyndon wrote: > 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. This is exactly what the patch does. That however happens in two parts, explained below. lyndon wrote: > 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. And therefore, this is not what the patch does. With the patch, upas/fs issues a "copy" command to the IMAP server, to copy the message from a folder to another folder inside the IMAP server, for the exact reasons that you presented. In my presented design, issuing the "store +flags \deleted" portion is left to the responsibility of the MUA, for example nedmail. However, I will send a version of the patch, that is in my opinion more elegant, soon separately. That version combines the copy and delete commands into one move command in the upas/fs level, which seems better than having the client deal with deletion separately, as it simplifies the MUA's duties. lyndon wrote: > 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. This reveals a shortcoming of my patch. It indeed only enables one to move mails inside an IMAP server, and not between IMAP servers. It also does not allow one to put new messages to an IMAP server. That is for simplicity and performance reasons. However, at least I only need to move mails inside an IMAP server, which is why the patch only does that. Thanks, rsal