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

Bron Gondwana <[email protected]>
Newsgroups gmane.mail.imap.general
Message-ID <[email protected]>
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
  [email protected]
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.