Hi Albrecht, On 03/12/2019 04:16:10 PM Tue, Albrecht Dreß wrote:
Hi Peter:
If RTTs are still an issue, we would need a more careful fix. From the look of the code, it appears that the intent was to find the nearest common ancestor of the old path to the folder and the new one, and re-scan just from that node. If the heuristic for finding it ever worked, it clearly no longer does, but a more careful search could probably be constructed.This is of course correct… However, as the folder has already been renamed in the first step, there is no need to establish a new connection for the LIST and LSUB queries - they just re-use the same connection (you can see that if you enable libnetclient debug messages). This completely avoids the costly start of encryption, login, etc. process for the scan. The full LSUB and LIST processing for my (though not very complex; ~10 folders in 3 nesting levels) ISP IMAP connection at ~1.5MBit/s needs ~200ms (remember that RFC 3501, sect. 6.3.8 requires “The LIST command SHOULD return its data quickly, without undue delay.”, and I don't see a reason why a server should be slower for LSUB, to be honest). Looking at the debug output, in my use case I estimate that the payload size for starting the encryption, logging in and renaming makes up > 50% of the total data volume. If the connection is /so/ slow that this might be a show-stopper, I wonder how long it would take to load a real-life message from the server… Just my € 0.01, though – if someone uses IMAP over, say, packet radio at 9.6kBaud every byte counts, of course!
Well, in case Balsa *has* such a bandwidth-challenged user: the attached patch finds the nearest common ancestor, and scans from there. It also has some NULL guards that seem to be needed. I've tested it with a toy folder tree on a gmail server. What do you think?
Actually, this patch has been a byproduct of a larger change I'm preparing, which addresses subscription management and choosing the folder for renaming. As to simplify life, I also re-scan the server structure instead of relying on the cached data. I will re-think this approach…
Looking forward to that!
Cheers, Albrecht.
Best, Peter
Attachment:
rename-imap-folder.diff
Description: Text Data
Attachment:
pgp3kLqBqOtLC.pgp
Description: PGP signature