51 lines
2.0 KiB
Plaintext
51 lines
2.0 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Fri Mar 21 22:38:28 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
Date: Fri Jun 8 12:34:52 2018
|
|
Subject: [Imap-protocol] IMAP SUBMIT Extension, take two
|
|
In-Reply-To: <abe79532-3a9d-4083-be13-7a4208ce3e37@gulbrandsen.priv.no>
|
|
References: <5f20eeec-c84b-4395-b89b-dfc243d9c465@flaska.net>
|
|
<66E46BE7-0C45-4EFD-B18F-5A6959AADAC4@gmail.com>
|
|
<db2cac03-876f-4966-bf1f-1a7f8d9f4536@flaska.net>
|
|
<219fd97c-e1fd-48e4-b8ae-fcf96537a9bb@gulbrandsen.priv.no>
|
|
<1395341331.29069.96929213.1F949AAB@webmail.messagingengine.com>
|
|
<39b431a9-93a6-42b1-9cbe-5788d5958f43@flaska.net>
|
|
<1395369035.8071.97071749.6F2A6445@webmail.messagingengine.com>
|
|
<abe79532-3a9d-4083-be13-7a4208ce3e37@gulbrandsen.priv.no>
|
|
Message-ID: <1395466708.12498.97497269.27B0A52C@webmail.messagingengine.com>
|
|
|
|
On Fri, Mar 21, 2014, at 10:59 PM, Arnt Gulbrandsen wrote:
|
|
> On Friday, March 21, 2014 3:30:35 AM CEST, Bron Gondwana wrote:
|
|
> > Let's not confuse things with more flags.
|
|
>
|
|
> Or with making the client serve the server.
|
|
>
|
|
> This is about making the server submit mail. So why should the client need
|
|
> to do any locking? It's not particularly difficult to say "server should
|
|
> lock the message appropriately to prevent duplicate or repeated submission"
|
|
> and define an error code. Like this:
|
|
>
|
|
> C: a submit foo bar
|
|
> S: a NO [ALREADYSUBMITTED] blah
|
|
|
|
Locking shmocking. I don't so much care about the race between two clients,
|
|
or one client being silly enough to try to do things concurrently, I don't
|
|
think that's a likely scenario, given that sending is a user initiated
|
|
action.
|
|
|
|
It's about having the client able to discover whether the server believes
|
|
that the message has been sent, reliably.
|
|
|
|
Otherwise if there's a disconnection, the only way to know if the server
|
|
actually sent the message is to try to submit it again. That's opaque.
|
|
As a client user, I want to able to know.
|
|
|
|
It's a state change on the message, and state changes need to be discoverable.
|
|
|
|
Bron.
|
|
|
|
--
|
|
Bron Gondwana
|
|
brong@fastmail.fm
|
|
|