Hi Peter: Am 12.03.19 15:21 schrieb(en) Peter Bloomfield:
Thanks for the patch! Committed and pushed to GitLab.
Thanks for pushing!
We /might/ even consider to simplify the whole block starting at src/folder-conf.c, line 566, to just re-scanning the whole server, but as I mentioned above, the other two use cases work fine for me.That would simplify the code (which is sorely needed in that file!).
Yes!
It would add more round trips, but that's surely less of an issue than it was when that code was written (in the earliest years of this century!). 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! 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… Cheers, Albrecht.
Attachment:
pgpGRATK6VWKk.pgp
Description: PGP signature