Re: [9front] upas/fs: copy messages between IMAP folders

[Risto Salminen <risto.salminen@gmx.com>]

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