Hi Peter! Am 16.03.19 21:50 schrieb(en) Peter Bloomfield:
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?
It works for me, and the change to src/main-window.c (?) re-opening the shifted folder is really nice. However, for my ISP's connection the difference in data transmitted when moving a folder from “INBOX/Test 1/Test a” to ”INBOX/Test 2/Test a” is a total of 15 bytes sent and 238 bytes received (after decryption). To be honest, I wonder if this really justifies the extra complexity of the code, in particular as this is an operation which will typically be performed rarely. As a comparison, the login, starttls and authentication process sends 115 and receives 651 bytes, and reading the envelope of a single message item sends 85 and receives 547…
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!
…which has been delayed by real-life work and a flu, I hope I can prepare a proposal next week… Cheers, Albrecht.
pgpFYxi0OwkTw.pgp
Description: PGP signature
_______________________________________________ balsa-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/balsa-list
