GNU bug report logs - #63311
30.0.50; [PATCH] smtpmail-send-it split

Previous Next

Full log

Message #49 received at 63311 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 63311 <at> debbugs.gnu.org
Subject: Re: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split
Date: Wed, 01 Nov 2023 14:59:23 +0200

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: 63311 <at> debbugs.gnu.org
> Date: Wed, 01 Nov 2023 13:35:45 +0100
> 
> I'm reviving this old bug report because I think I have made some
> progress.  Here is a new patch that tries to send mail asynchronously.
> This seems to work for me but, of course, it needs testing, testing and
> even more testing.

Thank you for working on this.

I have several questions about it:

  . I'm not sure I understand how will the success/failure of sending
    be communicated back to the callers.  Currently, when the sending
    succeeds, there's a message in echo-area, and if the message was a
    reply, then Emacs marks the original message as "have been replied
    to".  How will this work with async sending?

  . What happens if sending fails for some reason?  It could be that
    the problem is detected by smtpmail itself, or it could be that
    some low-level code signals an error -- what happens in both
    cases?

  . With which MUA are you testing this?

  . What happens if another message is sent while the previous one is
    still being sent?

  . What did you try to do in Emacs while the message was being sent,
    and did you see any problems with the foreground responsiveness?
    For that matter, how long did it take for the background thread to
    send the message?  If that was short enough, like 1 sec or so, I
    suggest to test this with sending a larger message, like a message
    with a large attachment.  That's because the most important
    situation where async sending is valuable is when it takes a long
    time to send a message, either because it's a large message or
    because the connection is slow or unreliable.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.