Re: [Imap-protocol] IMAP SUBMIT Extension, take two

On Thursday, 20 March 2014 07:06:11 EDT, Arnt Gulbrandsen wrote:
> Is that atomicity really required?

What I think is needed is letting the client know how the operation ended 
up, which could be done by the usual tagged OK/NO. Another thing which I 
believe almost any client will do is marking the message as sent.

Given that the set of flags is standardized (both $SubmitPending and 
$Submitted as well as their combined meaning), I think that it's an obvious 
thing which builds on the (good parts of) LEMONADE to reuse them. Now, 
doing this on the server means that the clients save one round trip, and 
that you got the benefits of being able to detect what happens after a 
reconnect in the process. These two things make it beneficial in my book.

That said, if this flag manipulation would stand between the draft and the 
standardization process, I'm OK with removing that. However, please note 
that APPEND also carries a requirement on flag manipulation, so there's a 
precedent already.

> And if it is, I don't think 
> the three-step submit process gives you atomicity.

AFAIK "atomicity" is given as long as "atomicity" means "you'll know what 
happened unless the server went on fire". Do you see a possible race in 
there?

> I like it in general, but I'd prefer a two- or even one-step 
> process. Two-step could be "upload to outbox; submit from 
> outbox". You can do the atomicity thing by saying that servers 
> SHOULD lock a message in the outbox while it's being submitted, 
> and refuse to resubmit.
>
> Personally I don't think it's worth it. It's better to have 
> simplicity, even at the cost of the occasional duplicated 
> message.

I smell a misunderstanding here. All that the draft mandates is setting up 
message flags on each state transition, and refusing to send a message 
which already has a certain flag set. Does the current wording of the draft 
perhaps convey some other meaning? I'll be happy to reword it.

To clarify, I'm absolutely OK with a server which would contain a race 
condition between checking the flags and proceeding further. The automatic 
flag manipulation was not meant to guard against a deliberate attempt at 
sending a message twice, but to:

- mimick what was the LEMONADE way of working,
- give the client a tool to check the state upon a possible network 
failure,
- do automatically what a client would do itself anyway,
- cut the troundtrips.

Cheers,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol