65 lines
2.8 KiB
Plaintext
65 lines
2.8 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Fri Mar 21 22:49:30 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: <1395466708.12498.97497269.27B0A52C@webmail.messagingengine.com>
|
|
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>
|
|
<1395466708.12498.97497269.27B0A52C@webmail.messagingengine.com>
|
|
Message-ID: <1395467370.14106.97498869.10F29520@webmail.messagingengine.com>
|
|
|
|
On Sat, Mar 22, 2014, at 04:38 PM, Bron Gondwana wrote:
|
|
> 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.
|
|
|
|
More specifically, client "A" sends a submit command on my request and then
|
|
loses the connection. I connect with client "B" and I want to be able to see
|
|
if the message was sent or not.
|
|
|
|
Particularly if my reconnection is a day later, I'd rather see the "it was
|
|
sent" or "it wasn't sent" status, not see a flag saying "it was part way
|
|
through being sent" and have my client automatically send it now. A day
|
|
later it may not need to be sent any more if it wasn't already.
|
|
|
|
Undiscoverable state is bad. Client disconnections are orders of magnitude
|
|
more likely than server failure in the middle of send.
|
|
|
|
Bron.
|
|
|
|
--
|
|
Bron Gondwana
|
|
brong@fastmail.fm
|
|
|