Hi Albrecht:
On 02/10/2017 03:13:22 PM Fri, Albrecht Dreß wrote:
Hi Peter:
Am 10.02.17 18:43 schrieb(en) Peter Bloomfield:
So I'm guessing it's an incorrect implementation of pipelining in that
"IMPLEMENTATION jpop-0.1" server.
The version number does not inspire confidence...
Yeah, right?
Anyway, I wonder if pipelining is a really required feature? My assumption is
that the communication speed is basically limited by the network bandwidth, and
thus the gain introduced by it is somewhat limited. As Balsa is running
multithreaded, I guess the user won't even notice if we disable it completely.
Or am I completely wrong here?
A high-latency connection would suffer--think satellite. On near-broadband, I can see a
momentary pause between messages while the "RETR nn" command is sent, but I'd
guess it's at the millisecond level. So, I feel that it's worth keeping pipeline
capability, but we definitely need a fix for this broken server.
It's actually quite easy to fix for this particular server: the IMPLEMENTATION
is part of the CAPA response, so we can easily detect that we're talking to
jpop-0.1 and ignore its PIPELINING capability. If other servers had the same
problem, we could install a blacklist, but at this point it would have only a
single entry, so hard-coding seems adequate. I'm thinking of adding
PopHandle::does_not_pipe.
One alternative would be to add an "Enable pipelining" checkbox to the SMTP
server dialog, but its purpose would be obscure, and it's not clear how a user would know
to disable it, so I'm inclined against that solution.
Thoughts?
Peter
_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list
