Multiple SMTP connections in parallel

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Multiple SMTP connections in parallel

Albrecht Dreß
Hi all,

I am currently implementing the "automatic queue transmission after timeout" feature which has been discussed recently here.

This is simple if there is only /one/ smtp server.  But it gets difficult if the user has more than one server, probably with different responsiveness.  E.g. I send to one ISP via a local Postfix (fast and always reachable, let Postfix deal with any network issues), and to an other ISP directly (sometimes slow and unreachable).

Of course only /one/ simultaneous connection shall be open to a specific server.  But while the send process to one (possibly slow) server is running in a separate thread, there is IMO no good reason why the send process to an other (faster?) server should be delayed until the slow one is ready.

The difficult part is how this should be displayed to the user.  The present implementation has a dialogue which receives the progress information via IPC.  This is not feasible if multiple threads would feed their information into it, as each one would overwrite the information from the others.

I think the only usable solution would be either a separate dialogue for each SMTP server, or a single dialogue which dynamically adds and removes a section consisting of a label and a progress bar for each server.

A different situation occurs if the transmission is initiated in background by the timeout handler.  IMO, in this case no dialogue should be shown.  Instead, I think a notification (of level LIBBALSA_INFORMATION_MESSAGE) when the transmission is started and when it has been finished, either with success or with an error, should be shown.

What do you think?

Cheers,
Albrecht.
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multiple SMTP connections in parallel

Peter Bloomfield
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Albrecht:

On 06/09/2017 12:54:48 PM Fri, Albrecht Dreß wrote:

> Hi all,
>
> I am currently implementing the "automatic queue transmission after timeout" feature which has been discussed recently here.
>
> This is simple if there is only /one/ smtp server.  But it gets difficult if the user has more than one server, probably with different responsiveness  E.g. I send to one ISP via a local Postfix (fast and always reachable, let Postfix deal with any network issues), and to an other ISP directly (sometimes slow and unreachable).
>
> Of course only /one/ simultaneous connection shall be open to a specific server.  But while the send process to one (possibly slow) server is running in a separate thread, there is IMO no good reason why the send process to an other (faster?) server should be delayed until the slow one is ready.
>
> The difficult part is how this should be displayed to the user.  The present implementation has a dialogue which receives the progress information via IPC.  This is not feasible if multiple threads would feed their information into it, as each one would overwrite the information from the others.
>
> I think the only usable solution would be either a separate dialogue for each SMTP server, or a single dialogue which dynamically adds and removes a section consisting of a label and a progress bar for each server.
>
> A different situation occurs if the transmission is initiated in background by the timeout handler.  IMO, in this case no dialogue should be shown.  Instead, I think a notification (of level LIBBALSA_INFORMATION_MESSAGE) when the transmission is started and when it has been finished, either with success or with an error, should be shown.
>
> What do you think?

So the thread-per-server model would be used both for user-initiated sends (such as File => Send queued mail) and for timer-initiated sends, but the progress information would be presented differently, is that right? I like the outline, especially the single dialog with progress indicators dynamically added and removed. Smooth transitions would be really cool…

Best,

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlk8pkAACgkQH1/UtbkqdPVTXQCfRk4zQwexon3C/fylvAmqTCBm
2hkAoJpC7rbrz3g+fqK06HKbtxY1XwP+
=S0a0
-----END PGP SIGNATURE-----
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multiple SMTP connections in parallel

Albrecht Dreß
Hi Peter:

Am 11.06.17 04:09 schrieb(en) Peter Bloomfield:
> So the thread-per-server model would be used both for user-initiated sends (such as File => Send queued mail) and for timer-initiated sends, but the progress information would be presented differently, is that right?

Yes, this is my idea.  When the user selects "send" or "send queued", I think [s]he expects the dialogue to appear.  For a background operation, a dialogue popping up seems too intrusive to me, therefore use the notification area in this case.

An extra goody would be if we remember during a long-running transfer that the dialogue has been closed by the user, and then just emit the notification after it has been finished.

> I like the outline, especially the single dialog with progress indicators dynamically added and removed. Smooth transitions would be really cool…

I just discovered that GtkRevealer provides exactly this, and hacked a little test application - looks really cool, will be the way I'll implement it.

Sorry for the delay, but the simple task "just send in background" turned out to be a lot more complex than I first expected…

Thanks,
Albrecht.
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list

attachment0 (484 bytes) Download Attachment
Loading...